-----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
> <[email protected]> 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
>>>> <[email protected]> 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
> 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.
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iF4EAREIAAYFAlXLhMkACgkQAJxUfCtlWe2A3wEA0jrf9slDrcM92yhXpGpTzBbD
baQAYRUrJsNEI+frKx4BAM9gWVbmGr6U9KAwBdzUVkOFUmZmFj9h7BHFdDsniI1t
=7UNL
-----END PGP SIGNATURE-----
