OR-like dependency in PKGBUILD

ninuzzo · 2012-05-14 10:29:14

I have a package which depends on vim build with python support.
There are two packages that provide that: gvim (extra) and
vim-inteprete (aur). How do I let my package's users choose one of them?

If I put vim-inteprete as a dependency in my package (in the "depend" list), people who have gvim already will be forced to change because vim-inteprete marks gvim as a conflicting package.
If I put gvim, people who have vim-inteprete already installed will be installing gvim as a dependency for my package. gvim does not state vim-interprete as a dependency, because it is an unsupported AUR package. I guess what will happen is that the gvim installation will fail with the usual file-conflict error.

Is there any way or workaround to specify 'either this or that dependency' in a PKGBUILD?

Last edited by ninuzzo (2012-05-14 10:31:50)

lifeafter2am · 2012-05-14 11:56:03

Can you depend on vim-runtime?

ninuzzo · 2012-05-14 12:08:40

Unfortunately not. E.g. package vim depends on vim-runtime, but it is compiled without Python support, as you can check here. Slimv requires Python support built into vim or doesn't work at all.

I wonder if a problem like mine ever happened to someone else. In principle, it could happen between all official packages too.

I would schematize it this way: package C requires either package A or B to work. If either is installed, the dependency is fulfilled. It can also be that A conflicts with B or vice versa or both, but this doesn't matter to C. As long as there is either A or B installed, C dependencies are satisfied.

Last edited by ninuzzo (2012-05-14 12:10:14)

Trilby · 2012-05-14 12:18:18

If I were you, I'd check out PKGBUILDs for various apps that depend on a java runtime. There are different options for this, and I think I remember even getting the option to install one or the other when I installed a package that required them.

EDIT: OK, I guess each of them list "java-runtime" under privides. Is there any common name in the provides list for the two alternatives in your case?

Last edited by Trilby (2012-05-14 12:20:24)

ninuzzo · 2012-05-14 12:40:41

I have checked. Packages that depend on a generic Java VM implementation state either java-environment or java-runtime as a sort of fake dependency. This meta-package is then provided by specific Java implementations. E.g. in the openjdk6 PKGBUILD you will find:

provides=('java-environment=6' 'java-runtime=6' 'java-runtime-headless=6')

while, for example, in the yuicompressor PKGBUILD you have:

depends=("java-environment")

This is a solution, but it won't be easy in my case to convince both the gvim and vim-inteprete packagers to add a provides=('vim-python') or similar line for me. Since VIM supports a handful of languages for extensions, you can image how such provides lines may get cluttered... Or take another package that has a lot of possible configuration switches, e.g. Apache...

I think the problem should be best solved into my PKGBUILD, but maybe that needs modifications to the makepkg source code in order to implement this feature of OR-ed dependencies... unless there is a workaround I can devise into my PKGBUILD itself!

Last edited by ninuzzo (2012-05-14 12:42:40)

Lone_Wolf · 2012-05-14 14:38:28

A workaround could be to manipulate the depends array with if statements in a PKGBUILD.

a pseudo-code example would look something like this :

if gvim_installed= FALSE AND vim-interprete = FALSE
then 
   echo "This package requires either gvim or vim-interprete, but neither is installed"
   echo "Compilation aborted"
   return 1
else
   if vim-interprete_installed = TRUE
      then depends = depends + "vim-interprete"
      else depends = depends + "gvim"
   fi
fi

(sorry, my bash skills are not good enough to write the actual code)

Last edited by Lone_Wolf (2012-05-14 14:40:05)

ninuzzo · 2012-05-14 14:57:51

Thank you "lupo solitario"! I am using this quick&dirty workaround and it works:

if pacman -Qq gvim >/dev/null 2>&1; then
  depends=(gvim python2)
elif pacman -Qq vim-inteprete >/dev/null 2>&1; then
  depends=(vim-inteprete python2)
else
  echo "This package requires either gvim or vim-inteprete, but neither is installed."
  echo "Choose gvim if you want GUI support."
  echo "Compilation aborted."
  return 1
fi

Last edited by ninuzzo (2012-05-14 15:01:25)

tomk · 2012-05-14 15:51:11

No offense, but that's horrible.

Let's have some Arch-like simplicity here:
Depend on gvim, because that's the official package. Put some explanatory comments in the PKGBUILD about vim-inteprete, advising users of that package to edit the vim-slimv PKGBUILD as required.

ninuzzo · 2012-05-14 16:06:12

Thanks. That's what I did in the first place. I was looking for a better solution. Because I think most users won't bother to read the comment about vim-inteprete. I usually don't read all PKGBUILDs I install with yaourt.

I still think that a feature to specify OR-ed dependencies in makepkg would be generally useful.

Well, the problem is how to implement that? Unfortunately Bash does not support nested arrays, otherwise it would be neat and simple to specify any OR-ed dependencies as a nested array element, while the external array elements are AND-ed as it is now.

Stallman once said that languages for extensions and scripting should be as powerful as real programming languages, because you can never know what one would like to do with them. He was right, yet bash is a project of the FSF LOL

I would like to have a Lisp-based shell for everything. Yep, I am just another Lisp junkie ;-)

SidK · 2012-05-14 16:21:07

This is exactly where customizepkg comes in handy. You create the PKGBUILD configured against the official packages and tell them in the PKGBUILD (and the AUR comments) to use customizepkg if you're using the AUR package.

Last edited by SidK (2012-05-14 16:21:48)

tomk · 2012-05-14 16:33:07

ninuzzo wrote:

Because I think most users won't bother to read the comment about vim-inteprete. I usually don't read all PKGBUILDs I install with yaourt.

OK - I can see we're unlikely to agree here, but I'll just say that as a package maintainer, I believe you should be trying to minimise that kind of user sloppiness, not encouraging it with nasty automated kludges. Anyone who doesn't thoroughly read PKGBUILDs before building deserves any problems that they subsequently encounter.

ninuzzo · 2012-05-14 18:02:21

Thank you all for your suggestions. I am new here and am learning a lot! Arch Linux is the only Linux distro where you learn about Linux instead of using it like Windows LOL

E.g. I didn't know about customizepkg, thanks. This thread explains how it works. Basically it is a yaourt "plugin" that allows users to automatically apply changes to PKGBUILD files whenever they are installing or upgrading a certain package.

Very useful, I will try now use customizepkg to make the slimv Lisp environment work with the default vim package (which is text-mode-only) by adding python2 support to it. The only drawback is that one has to do that manually on his system and also has remember to use yaourt instead of pacman.

I dreamed that, if nested arrays would be supported by bash, and makepkg would support that too, I could simply write:

depends=((gvim vim-inteprete) python2)

meaning

(gvim OR vim-inteprete) AND python2

but I understand we cannot change Bash with a better programming language that supports array nesting

Anyway, I still think it isn't necessarily a bad thing if the PKGBUILD system evolved to provide more control of dependencies or to allow one to choose between some pre-defined set of built-time configuration options (pre-sets).

E.g. FreeBSD and maybe Gentoo allow the user to choose the most common switches and alternatives when building a package using a text-mode GUI interface, without requiring one to ever read the Makefile. I do not think this would be against the spirit of Arch Linux. And nothing is stopping you from editing the PKGBUILD/Makefile directly or using customizepkg if you need to build the port in an unsupported way. But sometimes one is in a hurry and just wants something installed right away, doesn't want to know how the program is built as long as it works along with the rest of the system.

If I had such a feature, a sort of "makepkg config" I could let the user choose one or another dependency, of course defaulting on the one that uses supported packages only for sanity or trying to minimize the number of new packages to build.

Or, if I would be able to specify dependencies using a more complex boolean expression like an AND of ORs instead of just an AND as I showed above, well, it isn't overcomplicated computer code, which would be against the KISS principle. Other solutions, including customizepkg, are not very KISS-like too and indeed they do not integrate so well with the rest of the system.

I think that even being able to write a full boolean expression to check dependencies would not be a bad idea. But I am a Lisp user, a language with a very simple and consistent syntax and where data can easily become code and vice versa :-)

Last edited by ninuzzo (2012-05-14 18:06:17)

qlb1234 · 2015-09-17 02:26:08

Bump.

I was surprised when I found that there's not such feature in PKGBUILD. I think there must be people out there who think the same way.
For example, one wrote an application using Qt as GUI and it's Qt4 and Qt5 compatible. What shall s/he write in the "depends" field? Either writing only "qt4" or "qt5-base" shut the door to the other group of user, and all the effort of creating the compatibility for both versions of Qt will be lost.

I don't think adding a simple routine to verify conditional dependencies in PKGBUILD system is against the KISS principle. Powerful doesn't mean complicated.

Last edited by qlb1234 (2015-09-17 02:26:28)

ewaller · 2015-09-17 03:38:15

This is a really old thread. I think it has reached its conclusion.

Arch Linux

#1 2012-05-14 10:29:14

OR-like dependency in PKGBUILD

#2 2012-05-14 11:56:03

Re: OR-like dependency in PKGBUILD

#3 2012-05-14 12:08:40

Re: OR-like dependency in PKGBUILD

#4 2012-05-14 12:18:18

Re: OR-like dependency in PKGBUILD

#5 2012-05-14 12:40:41

Re: OR-like dependency in PKGBUILD

#6 2012-05-14 14:38:28

Re: OR-like dependency in PKGBUILD

#7 2012-05-14 14:57:51

Re: OR-like dependency in PKGBUILD

#8 2012-05-14 15:51:11

Re: OR-like dependency in PKGBUILD

#9 2012-05-14 16:06:12

Re: OR-like dependency in PKGBUILD

#10 2012-05-14 16:21:07

Re: OR-like dependency in PKGBUILD

#11 2012-05-14 16:33:07

Re: OR-like dependency in PKGBUILD

#12 2012-05-14 18:02:21

Re: OR-like dependency in PKGBUILD

#13 2015-09-17 02:26:08

Re: OR-like dependency in PKGBUILD

#14 2015-09-17 03:38:15

Re: OR-like dependency in PKGBUILD

Board footer