Optional makedepends in makepkg

Xilon · 2007-10-28 07:53:45

I was looking over Lunar Linux and found that their moonbase is quite similar to ABS. I also noticed that their implementation of optional depends ("USE flags") seems quite simple and elegant, at least in the PKGBUILD. I know many people don't want this functionality, but some do. Makepkg isn't exactly friendly when it comes to custom PKGBUILDs, merging upstream changes to a PKGBUILD can be time consuming. I think the most common changes to PKGBUILDs would be to add/remove dependencies.
The way Lunar Linux takes are of this is by having a (I would assume) function which concatenates an $OPTS variables. The parameters passed to this function are the name of the package, the configure parameter(s) if the package exists/is to be installed and if the package doesn't exist/is not to be installed and a description of the dependency. This is simple, and quite flexible.

This doesn't really have anything to do with pacman, it's not about optional dependencies for the binary package, it's about actually compiling support for various things.

I tried doing a quick proof of concept, but it turns out bash doesn't support multi-dimensional arrays, so I couldn't keep it consistent with the rest of the PKGBUILD syntax. I don't really know how to go around this, Lunar just has a function, but that means you have to have a "optional_makdepends ..." line for each dependency. We could simulate a multi-dimensional array, so the array would look like:

optional_makdepends=(
  "foo" "--with-foo" "" "support for foo"
  "bar" "--with-bar" "" "support for bar"
)

But this looks odd and would require extra calculation for the array indices. Anyway, here's the proof of concept that I wrote up:

# Implementation in makepkg
OPTS=
if [ ${#optional_makedepend[@]} -gt 0 ]; then
  if [ `pacman -Q ${optional_makedepend[1]} 2> /dev/null | wc -l` -ne 0 ]; then
    OPTS="$OPTS ${optional_makedepend[2]}"
  else
    OPTS="$OPTS ${optional_makedepend[3]}"
  fi
fi

# This is how it would look in the PKGBUILD
optional_makedepend=("sqlite3" "--with-sqlite" "" "database support")

build() {
  ./configure --with-foo \
    $OPTS
}

This wouldn't be exclusive to ./configure, since the parameter is just a string. It will work with any system that accepts parameters, it could even work with Makefiles like "-DWITH_SQLITE".

The script doesn't necessarily have to check if a package is installed on a system, it could prompt the user if they want to install the optional packages. Imo it would be best to have both, with the above method as default, and a switch to prompt the user.

I wanted to post his here to see how many people would actually be for this, and then maybe post it on the ML.

I'm not really that eager to implement this, but it would be nice. There are a bunch of package which depend on things that I wouldn't use in a million years, and it would be great to quickly checkout ABS, cd in and makepkg without having to worry about modifying the PKGBUILD each time there's an update, or patching it and resolving conflicts, etc.

Also, please don't flame this straight away saying "ZOMG GENTOO USE FLAGS POOP", it's not.

voonte · 2007-10-28 11:33:33

I think optional dependencies would be an excellent idea. However, there is one thing to consider before implementing this, does Arch really want to simplify the package customization process, or not? Arch has a lot of potential to grow in this area, but if the goal is to have a somewhat efficient and simple system to deal with single packages, Arch is already there.

In my opinion, Arch can have a much better source management system, to complement the excellent binary packages. Anyway, I would love to see Arch expand.

Xilon · 2007-10-28 12:17:12

I think makepkg at this point is primarily a dev tool. It's not that great for users who want to customise packages at all. I don't want this to become a full blown portage type package manager, where you recompile your whole system (yaourt can do that already afaik), but just to make it a bit nicer for people to customise the deps.

voonte · 2007-10-28 15:34:32

The idea of having more control over source packages is not to "recompile the whole system", rather to control the areas where you see fit. Also, I agree with you that makepkg is primarly a developer tool. I would love to see it target users more. Another thing I would like to know is how Arch's KISS philosophy is interpretted in this situation. What about DRY?

The best way to get some momentum in this is to try the changes you suggested and see how it works.

stonecrest · 2007-10-28 17:18:47

Well, I gave my thoughts on IRC - that I think this adds very limited capability for the additional complexity (and yes, having yet another possible line in the pkgbuild is additional complexity for people to understand).

That said, I just wanted to make one comment on your code: calling it an optional_makedepends isn't strictly correct. In your example, sqlite3 would also need to be a straight dependency, as you presumably can't compile foo with sqlite3 and then uninstall sqlite3 after the package is created. However, I'm not sure that this is always the case, which would make things tricky...

shining · 2007-10-28 18:51:35

stonecrest wrote:

Well, I gave my thoughts on IRC - that I think this adds very limited capability for the additional complexity (and yes, having yet another possible line in the pkgbuild is additional complexity for people to understand).

I'm also afraid that might be true.

That said, I just wanted to make one comment on your code: calling it an optional_makedepends isn't strictly correct. In your example, sqlite3 would also need to be a straight dependency, as you presumably can't compile foo with sqlite3 and then uninstall sqlite3 after the package is created. However, I'm not sure that this is always the case, which would make things tricky...

I was thinking about this problem too, but just adding the package to the depends array in the same time the configure flag is added to OPTS might be doable, and good enough.

Xilon · 2007-10-31 07:02:45

stonecrest wrote:

Well, I gave my thoughts on IRC - that I think this adds very limited capability for the additional complexity (and yes, having yet another possible line in the pkgbuild is additional complexity for people to understand).

I don't think it's that much more complex. When making a PKGBUILD and setting up the configure options, you need to figure out which packages are needed, etc. This array simply reflects that. It would also help with some packages that are somewhat monolithic, when the application itself is "modular", like the xmms2 package - of course this requires compiling.

stonecrest wrote:

That said, I just wanted to make one comment on your code: calling it an optional_makedepends isn't strictly correct. In your example, sqlite3 would also need to be a straight dependency, as you presumably can't compile foo with sqlite3 and then uninstall sqlite3 after the package is created. However, I'm not sure that this is always the case, which would make things tricky...

Going against the DRY principle, you could just put the packages in both arrays. I chose "optional_makedepends" because of the suggested optionaldepends. It seems these will go hand in hand with what's suggested here.

Arch Linux

#1 2007-10-28 07:53:45

Optional makedepends in makepkg

#2 2007-10-28 11:33:33

Re: Optional makedepends in makepkg

#3 2007-10-28 12:17:12

Re: Optional makedepends in makepkg

#4 2007-10-28 15:34:32

Re: Optional makedepends in makepkg

#5 2007-10-28 17:18:47

Re: Optional makedepends in makepkg

#6 2007-10-28 18:51:35

Re: Optional makedepends in makepkg

#7 2007-10-31 07:02:45

Re: Optional makedepends in makepkg

Board footer