On Tue, 20 Jan 2015 09:28:21 -0800 Zac Medico <zmed...@gentoo.org> wrote:
> On 01/20/2015 01:11 AM, Alexis Ballier wrote: > > On Tue, 20 Jan 2015 01:01:41 -0800 > > Zac Medico <zmed...@gentoo.org> wrote: > > > >> On 01/20/2015 12:13 AM, Alexis Ballier wrote: > >>> On Mon, 19 Jan 2015 20:31:45 +0100 > >>> Michał Górny <mgo...@gentoo.org> wrote: > >>>> 2. Subslots work correctly. Rebuilds are forced when the chosen > >>>> library is upgraded. Moreover, USE flag change causes a rebuild > >>>> when user decides to change the ffmpeg provider. > >>> > >>> > >>> No offense, but this argument is complete crap. You should rather > >>> fix portage bugs than propose to introduce tree-wide changes to > >>> hide them... More precisely: || ( a:= b c:= d ) is perfectly > >>> defined (in the "what it means" sense, not in PMS sense). When the > >>> package is built, if 'a' is satisfied then a (and its subslot) is > >>> added to the subslot list of the package; ditto for c. You end up > >>> with a list of subslot deps, that you can store in vdb or > >>> whatever, and use that to decide when to rebuild the package. > >> > >> That's an interesting proposal, but I immediately find myself > >> questioning how closely it models reality. For example, maybe the > >> package links to both the a:= package and c:= package, or maybe > >> just to one of them. Shouldn't our model match reality as closely > >> as possible, as long as it's practical? > > > > Do you have any such example ? > > Well, I think this demonstrates the sorts of ambiguities that may > arise when using || deps to model reality. We may find that replacing > || deps with USE conditionals and REQUIRED_USE constraints gives us a > more accurate and practical model for some kinds of dependencies. for the above example, yes of course, but this is because it is another instance of automagic deps since you don't control to what the package links to. > > I think we can only make the safest assumption. Even without > > subslot, if you consider this: || ( a b c d ), with a and c > > installed but package automagically deciding to use only a, how can > > a PM decide whether it is safe to remove a or not after the package > > has been merged ? > > Right, this demonstrates that || deps are ambiguous. So, maybe we > should look at alternatives that are not so ambiguous, such as USE > conditionals and REQUIRED_USE constraints. if you assume there are no automagic deps, what is wrong and/or ambiguous with '|| ( a b c d ) means "any of them, and at least all that were available when the package was merged"' ? in the above example this avoids PM breaking people systems by removing 'a' (e.g. if another packages pulls in 'd' that has a blocker against 'a') and as a side effect makes := deps work... Alexis.
