[Exherbo-dev] Labels - cross and granularity

Johannes Nixdorf 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)
>     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.

    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)
        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

    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
        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
        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 at target dependencies
> (and mainly shows that the full matrix of "how" and "when" labels isn't
> needed).
> 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 mailing list