Re: [gentoo-dev] New virtuals for libudev and libgudev

[Michał Górny]

Dnia 2014-03-28, o godz. 19:53:07
Rich Freeman <rich0@g.o> napisał(a):

> On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina
> <zerochaos@g.o> wrote:
> > All in all, this isn't a bad idea on the surface, but the first
> > arguement shows immediately when this is scaled up.  How many other
> > packages have multiple libs with different sonames? Off hand, I can
> > think of poplar, but I'm sure there must be more.  Is it really
> > scalable, desirable, or sane, to break each package on the system into
> > multiple different virtuals like this?
>
> Clever idea, actually, though I'd be interested in whether anybody
> else can think of any unintended consequences.
>
> I agree that there could end up being many cases of this, but that
> really just amounts to clutter, and more granular dependencies (which
> also make me think that a next step could actually be packages that
> only install the necessary libraries, and somehow controlling this by
> dependencies rather than USE flags which are a bit more cumbersome).

This is the other side of this. People already requested libudev
without whole udev, and this is a way of allowing it in the future.

> There really isn't anything special about virtual packages other than
> the fact that they don't install anything.  I wonder if it would make
> sense to actually create a new category for virtuals that only exist
> to express library dependencies.  Functionally it would be no
> different, but it would split up the namespace so that we don't have
> an additional 193 packages in the virtual category.  Plus, when
> looking at ebuilds it will be a bit more clear what each dependency is
> actually pulling in.

I have already suggested separate category for perl virtuals but been
quieted down at the time. I doubt people really want another category
for virtuals since some of their poor tools rely on 'virtual/'.

> One thing you didn't mention in your email is the interaction with
> conventional virtuals.  The dep string for libudev reads:
> RDEPEND="
>         || (
>                 >=sys-fs/udev-208:0/0[${MULTILIB_USEDEP},static-libs?]
>                 >=sys-apps/systemd-208:0/2[${MULTILIB_USEDEP},static-libs(-)?]
>                 >=sys-apps/systemd-208:0/1[${MULTILIB_USEDEP},static-libs(-)?]
>                 >=sys-apps/systemd-208:0/0[${MULTILIB_USEDEP},static-libs(-)?]
>                 >=sys-fs/eudev-1.3:0/0[${MULTILIB_USEDEP},static-libs?]
>         )"
>
> What happens if eudev-209 and udev-209 don't bundle the sane SONAME
> for libudev, and thus need different subslots?  The virtual libudev is
> versioned 208.

There's an exact subslot dep in there (:M/N). If either of them changes
SONAME of any of the libraries, the provider subslot is bumped
and the virtual no longer matches it.

The systemd deps are a good example of that. The subslots 0, 1 and 2
correspond to changes in libsystemd.so. Now, if any of SONAMES
in systemd change, it will have subslot 3 and the virtual will no
longer match. If it's libudev or libgudev changing, we'd introduce
a new version (subslot) of the virtual; otherwise, a new revision with
systemd:0/3 added.

In fact, the versions are not even really necessary there.

-- 
Best regards,
Michał Górny