-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/08/15 11:55 AM, Alexis Ballier wrote: > 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.
..if I'm understanding what you're saying here, you see this as something the PM will use to adjust the input use list so that the emerge itself will go ahead with the newly adjusted flags; am I understanding that correctly? In other words, there won't be any user control/alert/override for what the default actions will be, if the user's profile isn't set up in a way that satisfies REQUIRED_USE, correct? so if I have 'app-cat/pkg qt4' in my package.use, but USE="qt5" in my profile, then because both flags end up being enabled the REQUIRED_USE="^^ ( +qt5 qt4 )" in app-cat/pkg will just force-off my package.use entry and everything will proceed as if it wasn't there? > >> 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. Yes, just as it is now, the use-defaults in IUSE are part of the "input use". What I'm wondering is, would the +foo in REQUIRED_USE="|| ( +foo bar )" be something that should be used in combination with IUSE="+foo" (perhaps even require it) or would its functionality and specification be entirely independent of it? Right now for ||(), setting IUSE="+foo" gets around that issue in almost all cases, the only case it doesn't is when the user has explicitly set USE="-foo" (or USE="-*"). > > > [...] >> 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? This assumes that the PM will just set the flags that resolve the REQUIRED_USE directly (ie modify the "input use" based on the defaults provided) and go ahead, which seems to be what you're implying will be the implementation, earlier on. See my response re #1 above as well, since if I understand this correctly the REQUIRED_USE="|| ( +foo bar )" will set +foo even if USE="-*" in the profile right? > >> 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. Thinking about it I think I answered my own question, in that there shouldn't be any need for this to affect VDB since the end-result is expressed in the state recorded in 'USE'. And no VDB change means no need for a revbump. Whether or not the change results in a rebuild on -N will depend on whether or not the state of the user's profile will result in a REQUIRED_USE conflict that needs to be default-resolved or not, and that's true from emerge to emerge no matter what. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlXLc+MACgkQAJxUfCtlWe3GKgEAvfYZ3SD2NcKCeZjf4qlfzy2G Fjzfub0X2BfuiAVJnbgA/RIaxTQRGt7PL693qNS3HxOX/q2T7l6W3Hv105NeBTlT =S9wv -----END PGP SIGNATURE-----
