On Wed, 12 Aug 2015 12:27:15 -0400 Ian Stakenvicius <a...@gentoo.org> wrote:
> -----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? Answering all the above questions I think: input use and "effective" use are unrelated. The point here is to give PM a way to solve REQUIRED_USE which we currently lack. How PM does it: by autounmask-write, a warning, an error (as currently), or silently is up to each user's preference. I agree though that forcibly solving the conflicts silently might not be a terrible idea and it'd be much better to have an option to control that behavior. Alexis.
