On Wed, 12 Aug 2015 13:39:21 -0400
Ian Stakenvicius <a...@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 12/08/15 01:22 PM, Alexis Ballier wrote:
> > On Wed, 12 Aug 2015 13:06:43 -0400 Ian Stakenvicius
> > <a...@gentoo.org> 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
> >>>> <a...@gentoo.org> 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).
> >
>
> I don't think we've overseen that. If there's a conflict due to any
> two flags being set in ^^ ( +a b c d ), the default resolution is to
> enable a and disable b,c,d. Doesn't matter if a is one of the ones
> enabled or not.
>
> If you want to try and roll out the syntax, such that for any
> particular given set of flags being enabled there is a preferable
> default, then yes it'll have to be written out longhand for sure.
>
> OR we could just adjust PMS to assume flag order determines
> precedence and still not bother with a new operator: For "^^ ( a b
> c )" if a then b,c forced-off; elif b then c forced-off; elif !c
> then a forced-on; fi
that's another possible option indeed
> > Finally, about getting the logic right, since it's a subset of
> > the current syntax I don't think that should be a problem :)
>
> The superset of the "{,!}flag1? ( {,!}flag2 )" syntax was requested
> and created I believe -because- dev's were finding it
> difficult/annoying to write the logic out longhand and get it right.
:)
I'd rather bet it's been copied from what we're used to: license & dep
strings.
> AND it made the messages a lot more clear to end-users too, as I
> recall, as "only-one-of ( flagset )" is a lot more clear and concise
> than "flag1-enabled so must-enable/disable-the-rest-in-flagset." I
> didn't pay that much attention at the time though so if anyone
> involved with those operator requests etc could chime in on
> reasoning I'd appreciate it.
I think autounmask-write is much more clear than any kind of error
message
