1 |
On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina |
2 |
<zerochaos@g.o> wrote: |
3 |
> All in all, this isn't a bad idea on the surface, but the first |
4 |
> arguement shows immediately when this is scaled up. How many other |
5 |
> packages have multiple libs with different sonames? Off hand, I can |
6 |
> think of poplar, but I'm sure there must be more. Is it really |
7 |
> scalable, desirable, or sane, to break each package on the system into |
8 |
> multiple different virtuals like this? |
9 |
|
10 |
Clever idea, actually, though I'd be interested in whether anybody |
11 |
else can think of any unintended consequences. |
12 |
|
13 |
I agree that there could end up being many cases of this, but that |
14 |
really just amounts to clutter, and more granular dependencies (which |
15 |
also make me think that a next step could actually be packages that |
16 |
only install the necessary libraries, and somehow controlling this by |
17 |
dependencies rather than USE flags which are a bit more cumbersome). |
18 |
|
19 |
There really isn't anything special about virtual packages other than |
20 |
the fact that they don't install anything. I wonder if it would make |
21 |
sense to actually create a new category for virtuals that only exist |
22 |
to express library dependencies. Functionally it would be no |
23 |
different, but it would split up the namespace so that we don't have |
24 |
an additional 193 packages in the virtual category. Plus, when |
25 |
looking at ebuilds it will be a bit more clear what each dependency is |
26 |
actually pulling in. |
27 |
|
28 |
One thing you didn't mention in your email is the interaction with |
29 |
conventional virtuals. The dep string for libudev reads: |
30 |
RDEPEND=" |
31 |
|| ( |
32 |
>=sys-fs/udev-208:0/0[${MULTILIB_USEDEP},static-libs?] |
33 |
>=sys-apps/systemd-208:0/2[${MULTILIB_USEDEP},static-libs(-)?] |
34 |
>=sys-apps/systemd-208:0/1[${MULTILIB_USEDEP},static-libs(-)?] |
35 |
>=sys-apps/systemd-208:0/0[${MULTILIB_USEDEP},static-libs(-)?] |
36 |
>=sys-fs/eudev-1.3:0/0[${MULTILIB_USEDEP},static-libs?] |
37 |
)" |
38 |
|
39 |
What happens if eudev-209 and udev-209 don't bundle the sane SONAME |
40 |
for libudev, and thus need different subslots? The virtual libudev is |
41 |
versioned 208. |
42 |
|
43 |
Would it make more sense to version the virtual after the actual |
44 |
SONAME, and state the dependency in terms of ranges. That is |
45 |
libudev-1.0.0 is satisfied by udev-208 through udev-215, and eudev-208 |
46 |
through eudev-216 (with all the headaches of ranged dependencies - |
47 |
especially since the final version number isn't known when the first |
48 |
version is introduced)? So, instead of having many virtual packages |
49 |
with the same subslot, you'd have one virtual for each subslot, but |
50 |
which is satisfied by a number of versions of the real package. |
51 |
|
52 |
These sorts of issues are less of a problem if the virtual doesn't |
53 |
depend on multiple packages - that is, it isn't a virtual in the |
54 |
conventional sense at all. libudev is what might be considered a |
55 |
compound virtual in that we're overloading two different things in a |
56 |
single PV. |
57 |
|
58 |
Part of me wonders if a more elegant solution is some way of |
59 |
auto-generating library dependencies of some kind - basically |
60 |
extracting all the libraries from any package that installs them and |
61 |
creating virtuals matching their SONAMEs. Really this is just a way |
62 |
of caching SONAME info (which also allows a package manager to detect |
63 |
SONAME changes before even starting a build). I'm not sure that |
64 |
virtuals are the best way to capture this - it is just a mechanism |
65 |
that works with EAPI5. |
66 |
|
67 |
Those are just some of the potential issues/perspectives/etc I could |
68 |
think of offhand, and none of them are fully thought-out... |
69 |
|
70 |
Rich |