-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/08/13 10:21 AM, Ian Stakenvicius wrote: > On 05/08/13 01:58 PM, Alexis Ballier wrote: >> On Mon, 5 Aug 2013 18:28:54 +0100 Ciaran McCreesh >> <ciaran.mccre...@googlemail.com> wrote: > >>> On Mon, 5 Aug 2013 12:51:48 -0400 Alexis Ballier >>> <aball...@gentoo.org> wrote: >>>>> Not really. There's a tradeoff between dependencies that >>>>> are occasionally too strict, and dependencies that are >>>>> horribly complicated (see "subslot dictionaries"). >>>> >>>> having a way to express 'my subslot is the one of my >>>> provider' doesnt seem overly complicated >>> >>> Unfortunately things that "don't seem" to be complicated >>> sometimes are complicated. We haven't established whether >>> that's the case here. In particular, we don't have any notion >>> of "providers" currently, > >> s/currently/anymore/ > >>> and it's not clear such a concept makes sense as-is. We >>> haven't worked out what happens in a || ( a b !c ) case where >>> a, b and c are all installed, for example. > >> subslot = concatenation of the subslots of all (positive? if it >> makes sense) dependencies; updated when said dependencies get >> their subslot changed. > >> this seems to fit well for a virtual and should be in line with >> what one would get with old style virtuals in mind. > > > Except that's going to trigger even more of these unnecessary > rebuilds that you wanted to avoid -- what if a user has both > libjpeg-turbo and jpeg installed? Then a change in one (even if > that package wasn't built against it) is going to trigger a rebuild > of everything depending on the virtual. As would, I expect, the > emerge or unmerge of one of them, too. >
Now, if there was a way to determine the particular package (and its subslot value) via the SCANELF info (not possible I don't think), or if we were to implement virtual/jpeg as an exclusive-or instead of an inclusive-or (will break when two packages depend on explicit, different versions of libjpeg), then this could work more like what is expected. ... more research needed ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIBCp8ACgkQ2ugaI38ACPBeVgD9H5LAWDyLNjoRaWGtrOoLN35X Va/uEo9v7Wzc5psNt0cA/RZygrlCB70LDHX+vUJE/616xbUxWD/GjpvqVR7G/rok =xzxc -----END PGP SIGNATURE-----
