On Wed, 12 Aug 2015 11:30:39 -0400 Ian Stakenvicius <a...@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 12/08/15 11:08 AM, Ulrich Mueller wrote: > >>>>>> On Wed, 12 Aug 2015, Alexis Ballier wrote: > > > >> i.e. something that really tells the PM how to automate the > >> choice: - 'qt5 -> !qt4' is rather straightforward to solve and > >> tells the PM how (note that it is not equivalent to 'qt4 -> > >> !qt5') - '^^ ( qt5 qt4 )' requires the PM to make a choice in > >> order to automate it > > > > I was thinking about some syntax like this: > > > > REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )" > > > > The package manager would first evaluate each group in > > REQUIRED_USE with the original set of USE flags. If that doesn't > > evaluate to true, retry with flags changed as indicated by the + > > and - signs. > > > > Ulrich > > > > Having the ability for REQUIRED_USE to provide a default resolution > path should definitely help with things; I assume this is meant to > do its work via --autounmask-write or similar, ie to help users > adjust their config files? Or was the thought to allow PMs to > override USE immediately? I think it is better seen as a list of implications, esp. for this kind of questions :) With that in mind, there is no autounmask-write: effective USE for a given package is input USE with these implications applied. > Questions: > > 1 - how does +foo in REQUIRED_USE relate to use-defaults set in IUSE? This questions remains. I see use-defaults in IUSE as part of "input USE" above. [...] > 3 - will having REQUIRED_USE be able to force flags on (and others > off) likely result in abuse of profiles and other use defaults? I > forsee this being a way, for instance, for a dev to get around users > setting USE="-*" in make.conf to ensure a default use flag setting > is honoured. How? > 4 - Will a change to which flag the '+' is on likely to require a > revbump for VDB updates? For something like '^^ ( +qt4 qt5 )' I > could see maintainers wanting to switch which flag is default across > a bunch of packages at once when, say, the qt team wants qt5 to > become the de-facto default. It'll "require" a rebuild for those whose default changes anyway. I'd say no revbump since we don't revbump all affected packages when we add default enabled flags to make.defaults. Alexis.