Re: [gentoo-dev] [RFC] New ebuild metadata variables for filtering of binary package soname dependencies (analogous to Fedora __provides_exclude and __requires_exclude)

[Matthias Maier]

Am 29. Dec 2014, 09:46 schrieb Zac Medico <zmedico@g.o>:

> 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