[Exherbo-dev] Labels - cross and granularity

Alex Elsayed eternaleye at gmail.com
Wed Feb 3 23:26:04 UTC 2016

On Wed, 03 Feb 2016 23:52:08 +0100, Bo Ørsted Andresen wrote:


> 2) Change all our labels from defining when a dependency is used to
> defining how it is used. E.g. read:, import:, link:, exec:, etc.
> If this needs more fleshing out, I'll leave that to eternaleye..
> This might provide a lot of additional granularity but may also make the
> common case too complicated?

It's less changing them _from_ when a dependency is used, and more 
_adding_ how it is used as a separate thing.

There'd basically be two axes for dependencies: When it needs to be 
present, and how it is used.

On the "how" axis, I've wound up with:
- read: the dep contains data files which will be read by the package
- import: the dep contains code that will become part of the package
- link: the dep contains code that the package will refer to
- exec: the dep contains executables that the package will run

On the "when" axis, I feel the sensible values are:
- fetch: the dep is needed to download the package
- build: the dep is needed to go from source to binary
- test: the dep is needed when tests are run
- install: the dep is needed to run preinst/postinst/etc hooks
- use: the dep is needed when the package is used by the end user (or 
other packages)

Note "use" rather than "run" - "use" time is when a package can _satisfy_ 
dependencies, including read, build, and exec; only the last is apropos 
to "run".

The behavior of these regarding cross is as follows:

read: required on host, regardless of timing
import: required on target, regardless of timing
link: required on target, regardless of timing
exec: required on host at fetch and build; required on target at test, 
install, and use. At fetch and build time, dependencies of exec deps have 
their target == host.

To give some examples:

scm-git.exlib would add


app-text/dblatex would contain


cmake.exlib would add


x11-libs/libXv would have:


but also:


However, there are further cases as well.

For example, link implies _continuity_ of the dependency, while import 
does not - build+run=import would permit the build and run dependencies 
to be satisfied by different IDs, while build+run=link would, at least 
aspirationally, mean that they should be the same. This is useful in the 
case of static libraries and binaries: Presume LLVM was static-only, and 
that clang produced both a static binary and (under parts:devel) a static 
library. It should then have the following dependency:


	parts:devel? ( dev-lang/llvm )

That is, if another package requires clang's devel part, then clang 
requires LLVM be present - but it explicitly need not be the same build 
of LLVM.

Another corner case is C++ dependencies with templates. These contain 
code that is both imported and linked, like so:

	dev-lang/boost [[ note = [ not header-only ] ]]

As import shows that code was brought into the image itself, it probably 
should record the exact ID that satisfied it. This would allow tracking 
such things for security masks.

More information about the Exherbo-dev mailing list