Am 29. Dec 2014, 09:46 schrieb Zac Medico <[email protected]>:
> In order to implement something like this for Gentoo, we could add
> PROVIDES_EXCLUDE and REQUIRES_EXCLUDE ebuild metadata variables. These
> variables would be used to automatically generate PROVIDES and REQUIRES
> data for binary packages, based on the output of scanelf. The resulting
> PROVIDES and REQUIRES data would simply contain lists of sonames (and
> their corresponding ABIs, for multilib support), which would be used to
> resolve dependencies of binary packages. For example, the resulting
> REQUIRES and PROVIDES data for sys-libs/zlib-1.2.8-r1 built with
> ABI_X86="32 64" might look something like this:
>
> REQUIRES: X86_64: libc.so.6 386: libc.so.6
>
> PROVIDES: X86_64: libz.so.1 386: libz.so.1
So this basically shifts information that is available only after a
merge (and e.g. checked in the preserved-libs feature) to the metadata
of the binary package?
> For libz, the new PROVIDES_EXCLUDE and REQUIRES_EXCLUDE ebuild variables
> would not be needed. However, for things like python and perl modules,
> these variables would be used to exclude unwanted sonames from REQUIRES
> and PROVIDES.
How do you intend to use the new metadata in detail?
Is it planned to introduce this as another dependency constraint on
binary merges? Will this become a 'hard' or 'soft' dependency?
E.g. consider two packages, libfoo-1 (soname libfoo-1) and bar linking
against libfoo. And libfoo-2 (with new soname libfoo-2) emerged
replacing version 1 on the binhost replacing libfoo-1, bar not rebuild.
We now have on the binhost:
libfoo-1 (soname libfoo-1)
libfoo-2 (soname libfoo-2)
bar (dynamically linked to libfoo-1)
(i) Currently, an update on a client (using the binhost) will upgrade
libfoo-1 to libfoo-2 and the preserved-libs feature will preserve
the necessary shared library libfoo-1 for bar.
(ii) What should happen with above metadata? Shall an update only
resolve to libfoo-1 and bar?
(iii) What if libfoo-1 is removed from the binhost? If libfoo-1 is
already merged on the client an update wrt (i) is still possible.
So, shall the preserved-libs feature be used as a fall back then?
(iv) If bar is rebuild on the binhost - which it should be nowadays -
above metadata information could be used to automatically remerge
bar on the client - but couldn't this already be done with a
slot-operator dependency?
Further, we currently have multiple approaches for ensuring consistency
of dynamic linkage, the "poor man's approach" revdep-rebuild, language
specific update scripts (for python, perl, haskell,...), the
preserved-libs feature and, finally, slot-operators.
This would be another iteration of a solution, this time for binary
merges. Can you give me an example where your proposed approach is the
only way to ensure consistency of dynamic linkage, or is conceptually
cleaner?
I, for my part, like the fact that such metadata generation would be
completely automatic.
Best,
Matthias
