[Exherbo-dev] Labels - cross and granularity
compnerd at compnerd.org
Sun Feb 7 22:48:43 UTC 2016
On Wed, Feb 3, 2016 at 3:26 PM, Alex Elsayed <eternaleye at gmail.com> wrote:
> 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
In terms of bike shedding: these mostly are terrible names. They are
ambiguous and confusing for those of us who are not primarily packagers. I
think that these are better alternative names:
read -> data (or share)
import -> static-link (or include)
link -> dynamic-link (or lib)
exec -> invoke (or libexec)
Im not particularly fond of the alternative suggestions, but it does make
it a bit more obvious without looking up what they are referring to.
Ive given two suggestions per label, the parenthetical having a scheme that
is more readily accessible to most packagers. The suggestion here
indicates both the behavioral aspect of the dependency as well as the file
system origin. The data that you are reading is usually from (/usr/)share,
the statically included content is from (/usr/)include, the dynamically
included content from (/usr/)lib, and the tools invoked usually live in
(/usr/)llibexec. The names here almost mostly map to common configuration
options (llibdir, includedir, libexecdir).
The more generic names that I have provided are based on the fact that the
description of the read dependency indicates that it is runtime data that
you will read, and has nothing to do with static configuration data used at
build time nor is it related to read(1p) or read(2). import has language
specific semantics in python and ObjC which are completely different whilst
bash has no such equivalent per se. The description was that this was
content that will be statically linked into your generated binary, so
indicating that explicitly seems reasonable. dynamic-link is in the same
vein, indicating that it consumes a DSO from the package, and makes it more
explicit that you are dynamically linking, and not statically linking.
exec, like read is too close to exec(1p) or exec(3), but is completely
That said, Im not sure I understand the need for the increased verbosity of
the requirements of a dependency in contrast to the current label set. You
are making the common use case more complex for no gain. The above set
really boils down to two sets: build time dependencies
(static-link/include, what you called "import") or run time dependencies
(everything else). Now, there are cases where the dependency is ambiguous
(e.g. provides pkg-config data which is used at build time, but the
remainder of the dependency is runtime), but the status quo is maintained
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.
Im afraid I do not understand this. host and target are being mixed here.
The three terms are:
build: the target of the machine performing the build
host: the target of the machine where the generated binary will be run
target: the target of the machine to be targeted when compiling. This is
only relevant for toolchain components.
> 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.
> Exherbo-dev mailing list
> Exherbo-dev at lists.exherbo.org
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Exherbo-dev