On Wed, 03 Feb 2016 23:52:08 +0100, Bo Ørsted Andresen wrote:
<snippity>
> 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
fetch=exec:
dev-scm/git
app-text/dblatex would contain
use=read:
app-text/docbook-xml-dtd
cmake.exlib would add
build=exec:
sys-devel/cmake
x11-libs/libXv would have:
build=import:
x11-proto/videoproto
but also:
build+use=link:
x11-libs/libX11
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:
build=import:
dev-lang/llvm
use=import:
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:
build+use=import+link:
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.
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
