Bug 795414 – [Future EAPI] automatic conditional dependencies

• Product: Gentoo Hosted Projects
• Status: CONFIRMED ---

[Description David Michael 2021-06-11 14:52:14 UTC]

I'd like to propose a method of specifying conditional dependencies in a way that would not violate metadata invariance, for when dependencies change in situations that are not expressible by USE flags.

I would suggest a USE-like syntax for built-in conditions represented by @name, which could be used in the same ways as USE flags in dependency definitions.  These conditional declarations would appear in metadata as-is with no processing, like USE flags.  (The "@" could be reminiscent of annotation syntax--i.e. not evaluated until runtime--or maybe be seen as an abbreviation of "automatic".)  The package manager may need to save the state of the evaluated condition for installed packages, described below.

There are currently three conditions I would like to handle with this:

1. @cross

This should behave as a USE flag that is set when [[ ${CHOST} != ${CBUILD} ]] and unset otherwise.  Packages that have alternate requirements when they can't build natively executable programs could use BDEPEND="@cross? ( ... )" to specify them.

It could be useful for packages that need to execute their installed binaries at build time, such as sys-devel/bc.  These packages could declare BDEPEND="@cross? ( ~${CATEGORY}/${P} )" and not have circular dependencies, but there are caveats to this usage...

2. @sysroot

This should behave as a USE flag that is set when [[ -n ${SYSROOT} ]] and unset otherwise.  It might be safer to use this than @cross when packages need to compile executable programs at build time.  For example x11-misc/colord or app-editors/emacs have many library dependencies that might not be installed on a minimal build system, like lcms2.  If building them natively in a sysroot, @cross would not be true, so their library dependencies would be installed in $SYSROOT and not $BROOT, so the runtime linker would not find them when trying to execute programs linked against them without LD_LIBRARY_PATH configured.  It would be better to use BDEPEND="@sysroot? ( ~${CATEGORY}/${P} )" instead to avoid circular self-dependencies.

3. @devel

This should behave as a USE flag that is set when a package is being installed as a build-time dependency and unset otherwise.  The primary use of this would be in RDEPEND or PDEPEND to install dependencies of development files.

Currently, Gentoo packages handle this situation in inconsistent ways.  For example, dev-libs/nss has RDEPEND="virtual/pkgconfig" because it installs the build-time-only script nss-config which calls pkg-config; however, X11 packages do not RDEPEND on x11-base/xorg-proto when their installed headers require it, since the compiled libraries and programs don't need it at runtime.

Being able to declare e.g. RDEPEND="@devel? ( virtual/pkgconfig )" on dev-libs/nss would allow the package to function as build dependency of something else, while also not building the unused pkgconfig if NSS was installed directly for its utility programs.  This would also result in cleaner systems that are built from binpkgs since they don't install anything as build-time dependencies.

This might require the package manager to save the state of the condition as it was evaluated for the installed package.  If NSS was installed directly, it would save that @devel was false, so if something else is installed that DEPENDs on NSS, the package manager could know that it needs to install the @devel dependencies.  This behavior might be too "magic" until GLEP 62 is implemented, then @devel would basically behave like an IUSE_RUNTIME flag which every DEPEND/BDEPEND definition implicitly requires.

4. @test

I'm not actually too concerned about this condition myself, but I thought it might make sense to suggest here.  This would behave as a USE flag that is set when FEATURES="test" and unset otherwise.  It could be a simpler alternative to bug #517658 to be able to specify DEPEND="@test? ( ... )" and BDEPEND="@test? ( ... )" rather than add even more dependency types, TDEPEND and TBDEPEND.  The package manager could use the existence and saved state of @test to orchestrate resolving circular dependencies as described in that bug, but that might extend the scope of this too much.