Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 12:27:15 -0400
Ian Stakenvicius <axs@g.o> 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
> > <axs@g.o> 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.