[aur-general] optional dependencies that require explicit installation

[Xyne]

On 2011-05-18 00:14 +0800 (20:3)
Ray Rashif wrote:

> On 17 May 2011 18:14, Michael Schubert <mschu.dev at gmail.com> wrote:
> > 2011/5/17 Ray Rashif <schiv at 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