[Exherbo-dev] Labels - cross and granularity
mixi at shadowice.org
Wed Feb 10 09:56:54 UTC 2016
After some discussion on IRC on how unacceptable it is to suggest
something that doesn't fix all known problems at once, I'd like to add a
few (more complex) labels to my proposal. After all proposing them is
easy enough and I don't have to implement them.
On Tue, Feb 09, 2016 at 01:46:58PM +0100, Johannes Nixdorf wrote:
> test: (+test-expensive)
> Use case:
> Binaries or data provided by a package are required for
> tests/expensive tests. (same as before)
> Required if tests are enabled. This means only if build == host.
> So in the cross case we only ever need to require them from the
> build host.
> Use case:
> Binaries or data provided by a package are required in the pkg_*
> functions. (same as before)
> Required from the build host at install time.
> build: (+fetch)
> Use case:
> Host-agnostic (or "host-symlink host"-specific) data/executables
> provided by a package are used at build/fetch time (executing
> host tools, etc.) (same as before)
> Required from the build host at build time only.
> Use case:
> Host-specific data provided by a package is used at build time
> (include files, static libraries, etc.) only.
> Required from the host host at build time only.
> run: (+post)
> Use case:
> Host-specific data/executables provided by a package are used at
> runtime. (same as before)
> Required from the host host at runtime.
Build-only dependencies only when cross-compiling (e.g.
icu/ncurses/python needs itself already installed on the build
host when cross-compiling)
When build != host the dependency is required on build time from
the build host.
Why no run-cross:
We want to guarantee that the cross-compiled package is the same
as if it were natively compiled for the host host, so we can't
have different behaviour (/dependencies) after installing. (Or
at least I'd like it if we guaranteed that)
Why no build-cross-native:
Because the name is ridiculous. Also I'm not convinced we'll
ever run into such cases. Theoretically it's possible though
that some native data package is only required when
cross-compiling (e.g. skalibs provides a directory called
"sysdeps" that provides host-specific information - if we split
that directory from the main package it'd only be required when
Shared data or host-symlink-providing host executables are
required at runtime (e.g. steam executing binaries that only
really need to be required on the current host-symlink-providing
I propose adding a knob to our configuration somewhere where it
makes sense implementation-wise (e.g. in the cross repository
configuration file if that makes sense) that specifies ideally
on a per-cross-host basis whether run-shared dependencies are
required to be provided from the host host or the build host.
Requiring those dependencies to be provided from the build host
breaks the switch-host-symlink and
only-copy-shared-data-from-host-host-packages use case (as
explained in the previous mail and
requiring them from the host host defeats the purpose of this
label. So make this configurable and let the user decide whether
he wants a x86/x86_64 multibuild-like host with minimal
dependencies based on this dependency label or whether he wants
a full-blown can-switch-host-symlink and
> For shared libraries we would now need to use build-native+run instead
> of build+run. The names are of course subject to bikeshedding.
> This proposal doesn't discuss suggestion/recommenation semantics for
> cross, which is something we probably need to consider too (if we break
> all dependency labels we might as well do it only once, but this
> proposal as it stands is backwards-compatible for now).
> Now to http://exherbo.org/docs/multiarch-TODO.html#labels:
> This proposal only finds a solution for build-time at target dependencies
> (and mainly shows that the full matrix of "how" and "when" labels isn't
> run-time at native dependencies are ruled out early on when making the
> first matrix out of a similar reason to the one mentioned on the page.
> It'll break the switch-the-host-symlink use case in the same way it
> breaks the only-copy-the-data-files-used-by-the-cross-host use case.
> Fixing this needs more complicated semantics than considered here.
> Regardless I'd like to propose run-shared as the name for the label (as
> it refers to shared data or host-symlink executables).
Now provided by run-shared.
> build-cross dependencies aren't considered either, as they need more
> complex semantics than were considered in here.
Now provided by build-cross.
All names are (of course) subject to bikeshedding. Just suggest your own
names here if you think you have better ideas than me on that account.
More information about the Exherbo-dev