[Exherbo-dev] Labels - cross and granularity
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
Note "use" rather than "run" - "use" time is when a package can _satisfy_
dependencies, including read, build, and exec; only the last is apropos
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:
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
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