Dnia 2014-03-28, o godz. 19:53:07 Rich Freeman <[email protected]> napisał(a):
> 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). 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
signature.asc
Description: PGP signature
