Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 13:06:43 -0400
Ian Stakenvicius <axs@g.o> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 12/08/15 01:05 PM, Ian Stakenvicius wrote:
> > On 12/08/15 01:00 PM, Alexis Ballier wrote:
> >> On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius
> >> <axs@g.o> wrote:
> >
> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >>>
> >>> On 12/08/15 12:42 PM, Ulrich Mueller wrote:
> >>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
> >>>>> 2 - is there a particular reasoning for the - in front
> >>>>> of qt4 here? I only ask because it would seem that a
> >>>>> single default-enable should suffice in lists like this
> >>>>> to indicate a resolution path, no? That is, '^^ ( +flag1
> >>>>> -flag2 -flag3 -flag4 )' to me seems like it would be the
> >>>>> same as '^^ ( +flag1 flag2 flag3 flag4 )'
> >>>>
> >>>> If the user has both "qt4 qt5", then enabling qt5 alone
> >>>> won't help to resolve "^^ ( qt5 qt4 )".
> >>>>
> >>>
> >>> Right, but the PM knows based on a particular REQUIRED_USE
> >>> operator what it would need to do when a particular flag is
> >>> set to default. Given '^^' is must-be-one-of, the +flag would
> >>> be enabled and all the other flags would be disabled, right?
> >>>
> >>> Here's how I'd see it mapping out:
> >>>
> >>> || ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ (
> >>> +flag1 flag2 ... ) , PM forces-on flag1, forces-off all
> >>> others ?? ( +flag2 flag2 ... ) , PM forces off all but flag1
> >>>
> >>> I'm not sure if the following make sense though... thoughts?
> >>>
> >>> {,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? (
> >>> +!flag2 ) , PM forces !flag2, meaning forces-off flag2
> >>>
> >>>
> >>> I'm just wondering if it's really necessary in terms of
> >>> syntax to specify the flag-negation that the PM would need to
> >>> do.
> >
> >
> >> See my other email: neither + nor - are necessary :)
> >
> >
> >
> >
> > I'd disagree on that -- technically they aren't necessary, but
> > the whole reason why these new operators were added in the first
> > place was so that it's a lot easier for developers to fill in
> > REQUIRED_USE and get the logic right.  Mapping out a ^^ ( flag1
> > flag2 flag3 flag4 ) into all of its permissible flag-a? ( flagb
> > !flagc !flagd ) variants is a royal pain.  Plus there's
> > readability/understandability to consider here.
> >
>
> err, flaga? ( !flagb !flagc !flagd )  i mean..

It is indeed longer (n flags to roughly n² flags expanded i'd say), but
i disagree on the readability: i find it much more readable as "if
flaga is enabled then flagb, flagc and flagd must be disabled" etc.
which express clearly the preference than "exactly one of flaga flagb
flagc flagd except if there is a problem then flaga but not the others".

Also, there's something we've overseen with the +/- syntax: What about
"^^ ( +flaga -flagb -flagc -flagd )" with USE="-flaga flagb flagc" ?
The only way to solve it would be USE="flaga -flagb -flagc" while the
"implication syntax" could give you USE="-flaga flagb -flagc" (or any
other preference of the ebuild writer).

Finally, about getting the logic right, since it's a subset of the
current syntax I don't think that should be a problem :)

Alexis.