[aur-general] optional dependencies that require explicit installation
Hi, I'm trying to make a PKGBUILD for a scientific library (libsbml). It has bindings for C/C++ that are installed by default and for a variety of other languages on demand. I'm not quite sure about the proper way to handle this: - for a language binding to be built, the package (e.g. python, perl, ruby, etc.) need to be installed and they need to be enabled in cmake using the -DWITH option - if a language binding is build, I need to set the path as well (because it is somewhere nonstandard by default) So, in order for this to work: - how should I check if a package is installed? I found no if-available option in the cmake scripts; pacman -Q would be an option (the best one?), or checking for the existance of a specific file (probably not so good) - if I'd like to separate build() and package() routines, is there a way of getting around adding each binding as a variable in global scope?- that does not seem like an optimal solution given the other packaging standards Thank you for any advice. Michael
Put them as make and optional deps :-)
2011/5/16 jesse jaara <jesse.jaara@gmail.com>
Put them as make and optional deps :-)
But make doesn't depend on them. Also, I wouldn't want to install <some weird programming language> in order to get the package to build. The best solution is probably to only use build() and put them as enable_x variables there. Still, I'm wondering if there is a proper way of doing this.
Then the way to go is to make a separate package for each. Liba-pytgon liba-perl...
2011/5/16 jesse jaara <jesse.jaara@gmail.com>
Then the way to go is to make a separate package for each. Liba-pytgon liba-perl...
Doesn't work when I want e.g. Perl and Python bindings.. unless I make a base and extension packages with is complete overkill for a relatively small library (and results in ridiculously long build times).
On 17 May 2011 05:20, Michael Schubert <mschu.dev@gmail.com> wrote:
2011/5/16 jesse jaara <jesse.jaara@gmail.com>
Put them as make and optional deps :-)
But make doesn't depend on them. Also, I wouldn't want to install <some weird programming language> in order to get the package to build.
That's the way it's done. You have those optdeps as makedeps so you can finish building the package. These deps will be installed as deps, so a -Qdt would show them as orphans. There is --rmdeps that takes care of this; makepkg -sr. -- GPG/PGP ID: 8AADBB10
2011/5/17 Ray Rashif <schiv@archlinux.org>
That's the way it's done. You have those optdeps as makedeps so you can finish building the package.
Sorry if I was a bit unclear earlier. The make process does not need all binding languages as dependencies as cmake and configure take care of preventing those from being built. So the make works fine with no optional dependencies installed. Just to make sure I understand you correctly, I should: - make a base package with C/C++ bindings only (as they are mandatory) - an additional package per binding that the user may want to install - listing the additional packages as optional dependencies from the base one - listing the binding language of each additional package as mandatory dependency there Thus, if I would like to install the package with 2 additional bindings it will be downloaded and build 3 times in order to get 1 functional installation: - the base package - the base package + binding x (2 times) Thanks.
On 17 May 2011 18:14, Michael Schubert <mschu.dev@gmail.com> wrote:
2011/5/17 Ray Rashif <schiv@archlinux.org>
That's the way it's done. You have those optdeps as makedeps so you can finish building the package.
Sorry if I was a bit unclear earlier. The make process does not need all binding languages as dependencies as cmake and configure take care of preventing those from being built. So the make works fine with no optional dependencies installed.
When you're distributing any modular package that, when installed with all usable dependencies, would provide full software functionality, someone (the builder/packager) has to initially configure and build the software with everything in place. * So, you first install all usable deps, build it, then remove the unimportant deps (thus making them makedeps + optdeps). If a dep cannot be removed (when a particular part of the software complains about something missing or does not work as expected), then it cannot be an optional dependency. Sometimes, in order to appease everyone, you must build and depend on deps that not everyone would need, because those deps are link-level or hardcoded once used (to build). . You don't have to build multiple packages just because of this, unless we're talking about a rather large software compilation/bundle. But yes, you may split the package in the end. If it is easier for you then build as many times within the PKGBUILD as needed, to for example a different directory each time. Then you can package separately and the result is a split package. Do this only if building in the optional support actually leads to unwanted bulk for those not needing the optional functionality. -- GPG/PGP ID: 8AADBB10
On 2011-05-18 00:14 +0800 (20:3) Ray Rashif wrote:
On 17 May 2011 18:14, Michael Schubert <mschu.dev@gmail.com> wrote:
2011/5/17 Ray Rashif <schiv@archlinux.org>
That's the way it's done. You have those optdeps as makedeps so you can finish building the package.
Sorry if I was a bit unclear earlier. The make process does not need all binding languages as dependencies as cmake and configure take care of preventing those from being built. So the make works fine with no optional dependencies installed.
When you're distributing any modular package that, when installed with all usable dependencies, would provide full software functionality, someone (the builder/packager) has to initially configure and build the software with everything in place.
* So, you first install all usable deps, build it, then remove the unimportant deps (thus making them makedeps + optdeps).
If a dep cannot be removed (when a particular part of the software complains about something missing or does not work as expected), then it cannot be an optional dependency. Sometimes, in order to appease everyone, you must build and depend on deps that not everyone would need, because those deps are link-level or hardcoded once used (to build). . You don't have to build multiple packages just because of this, unless we're talking about a rather large software compilation/bundle.
But yes, you may split the package in the end. If it is easier for you then build as many times within the PKGBUILD as needed, to for example a different directory each time. Then you can package separately and the result is a split package. Do this only if building in the optional support actually leads to unwanted bulk for those not needing the optional functionality.
-- GPG/PGP ID: 8AADBB10
Rephrasing and adding to what's already been said, the ideal would be to provide separate *non-mutually-exclusive* packages for each binding (python-foo, perl-foo, etc). That would let each user install exactly what they want. If that is not possible, then build the package with support for the default bindings, or whichever bindings are most common across distros if there are no official defaults. If binding support for foo requires that foo be installed *at runtime* (i.e. the package will display warnings and or not run without foo), then make foo a dependency (depends) of the package. If binding support only requires that foo be present at build time, make foo a build dependency (makedepends) and an optional dependency (optdepends). Users who wish to add or remove binding support not provided by the default package can simply edit the PKGBUILD and build a customized version. To facilitate this, split the build options across different lines in the PKGBUILD and comment the non-default bindings so other users can easily modify them. Add a few comments to remind users about updating the depends, makedepends and optdepends arrays when necessary. Regards, Xyne
Thank you Xyne and others, that was very helpful. I'm going to build standard bindings (Perl, Python) and add commented lines for the other ones. Michael 2011/5/18 Xyne <xyne@archlinux.ca>
On 2011-05-18 00:14 +0800 (20:3) Ray Rashif wrote:
2011/5/17 Ray Rashif <schiv@archlinux.org>
That's the way it's done. You have those optdeps as makedeps so you can finish building the package.
Sorry if I was a bit unclear earlier. The make process does not need all binding languages as dependencies as cmake and configure take care of preventing those from being built. So the make works fine with no
On 17 May 2011 18:14, Michael Schubert <mschu.dev@gmail.com> wrote: optional
dependencies installed.
When you're distributing any modular package that, when installed with all usable dependencies, would provide full software functionality, someone (the builder/packager) has to initially configure and build the software with everything in place.
* So, you first install all usable deps, build it, then remove the unimportant deps (thus making them makedeps + optdeps).
If a dep cannot be removed (when a particular part of the software complains about something missing or does not work as expected), then it cannot be an optional dependency. Sometimes, in order to appease everyone, you must build and depend on deps that not everyone would need, because those deps are link-level or hardcoded once used (to build). . You don't have to build multiple packages just because of this, unless we're talking about a rather large software compilation/bundle.
But yes, you may split the package in the end. If it is easier for you then build as many times within the PKGBUILD as needed, to for example a different directory each time. Then you can package separately and the result is a split package. Do this only if building in the optional support actually leads to unwanted bulk for those not needing the optional functionality.
-- GPG/PGP ID: 8AADBB10
Rephrasing and adding to what's already been said, the ideal would be to provide separate *non-mutually-exclusive* packages for each binding (python-foo, perl-foo, etc). That would let each user install exactly what they want.
If that is not possible, then build the package with support for the default bindings, or whichever bindings are most common across distros if there are no official defaults. If binding support for foo requires that foo be installed *at runtime* (i.e. the package will display warnings and or not run without foo), then make foo a dependency (depends) of the package. If binding support only requires that foo be present at build time, make foo a build dependency (makedepends) and an optional dependency (optdepends).
Users who wish to add or remove binding support not provided by the default package can simply edit the PKGBUILD and build a customized version. To facilitate this, split the build options across different lines in the PKGBUILD and comment the non-default bindings so other users can easily modify them. Add a few comments to remind users about updating the depends, makedepends and optdepends arrays when necessary.
Regards, Xyne
participants (4)
-
jesse jaara
-
Michael Schubert
-
Ray Rashif
-
Xyne