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)
> Semantic:
> 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.
>
> install:
> Use case:
> Binaries or data provided by a package are required in the pkg_*
> functions. (same as before)
> Semantic:
> 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)
> Semantic:
> Required from the build host at build time only.
>
> build-native:
> Use case:
> Host-specific data provided by a package is used at build time
> (include files, static libraries, etc.) only.
> Semantic:
> 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)
> Semantic:
> Required from the host host at runtime.
build-cross:
Use case:
Build-only dependencies only when cross-compiling (e.g.
icu/ncurses/python needs itself already installed on the build
host when cross-compiling)
Semantic:
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
cross-compiling).
run-shared:
Use case:
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
host)
Semantic:
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.
Reason:
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
http://exherbo.org/docs/multiarch-TODO.html#labels). Strictly
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
can-only-copy-shred-data-from-host-host-packages host.
> 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@target dependencies
> (and mainly shows that the full matrix of "how" and "when" labels isn't
> needed).
>
> run-time@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.
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
