On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina
<[email protected]> 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).
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.
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.
Would it make more sense to version the virtual after the actual
SONAME, and state the dependency in terms of ranges. That is
libudev-1.0.0 is satisfied by udev-208 through udev-215, and eudev-208
through eudev-216 (with all the headaches of ranged dependencies -
especially since the final version number isn't known when the first
version is introduced)? So, instead of having many virtual packages
with the same subslot, you'd have one virtual for each subslot, but
which is satisfied by a number of versions of the real package.
These sorts of issues are less of a problem if the virtual doesn't
depend on multiple packages - that is, it isn't a virtual in the
conventional sense at all. libudev is what might be considered a
compound virtual in that we're overloading two different things in a
single PV.
Part of me wonders if a more elegant solution is some way of
auto-generating library dependencies of some kind - basically
extracting all the libraries from any package that installs them and
creating virtuals matching their SONAMEs. Really this is just a way
of caching SONAME info (which also allows a package manager to detect
SONAME changes before even starting a build). I'm not sure that
virtuals are the best way to capture this - it is just a mechanism
that works with EAPI5.
Those are just some of the potential issues/perspectives/etc I could
think of offhand, and none of them are fully thought-out...
Rich
