Ryan Hill wrote: > Zac Medico <[EMAIL PROTECTED]> wrote: >> Ryan Hill wrote: >> > Though I'm still not sure what happens when a package is in two >> > unrelated sets.. >> > >> > @gnome: >> > RDEPEND=">=gnome-extra/gnome-screensaver-2.22.2" >> > >> > @xfce4: >> > RDEPEND="gnome-extra/gnome-screensaver" >> > >> > package.use: >> > @gnome opengl >> > @xfce -opengl >> >> I suppose we could use the order that they are listed in package.use >> to apply the incremental stacking, so opengl would be disabled since >> @xfce comes after @gnome. > > I guess I'll need to stop sorting my package.use then. :p > > But yeah, I have no better idea. If someone really needs to lock down > a USE flag on a pkg they can put the pkg atom itself into p.use. > Indeed, although a more natural approach might be to take whichever dependency is more specific (in the case where the user hasn't otherwise expressed a preference, and there is a conflict.) The more specific dep implies a closer relationship (although a warning would be useful ofc.)
Another way to express preference or association might be useful too, although a category heuristic would also aid automated decision-making (the set is being considered, so I'm guessing we know, which packages are listed in it; can easily query if not.) The fallback would be the simple position in the list. While this might sound like yet more special-casing it's the kind of thing that delights users ime, since it means less for them to worry about, and only runs in the case where the decision is not clear from the configuration and the tree. IOW something to specify as a 'may' rather than 'undefined.' (I still feel the same about losing 'world' ofc *sniff* ;)
