Re: [gentoo-dev] RFC: Future EAPI version operator changes

[konsolebox]

On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny <mgorny@g.o> wrote:
> On Wed, 9 Nov 2016 14:32:33 +0800
> konsolebox <konsolebox@×××××.com> wrote:
>
>> On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny <mgorny@g.o> wrote:
>> >>dev-foo/bar{:1.3 :1.4 :1.5}  ## Solves "A. Range dependencies vs
>> >>slotting"
>> >
>> > I'm not sure about this. Slots are kinda special, especially with regard to slot operators. Problems I see:
>> >
>> > 1. := binds to slot of newest version matching the spec. How does this work with your spec?
>> >
>> > 2. Should we allow using := on some of the listed slots? What would happen?
>> >
>> > 3. It's asymmetric since we can't use an AND variant.
>>
>> I had to ask help from #gentoo-dev-help in order to properly
>> understand slot operators since I haven't become too familiar with
>> them so sorry for the late reply.  (Thanks to desultory and _AxS_).
>>
>> Here I find it that we could just follow the simple AND/OR rule
>> against every condition from left to right, and the interpreter would
>> just do fine.  A user may create insensible rules just like how one
>> could create meaningless codes in C, but that won't stop the compiler
>> from compiling the code, just like how this would not prevent the
>> package manager from interpreting it.  We're also free to detect
>> ambiguous rules if we want to, and warn the user, or just disallow it
>> completely.  But it's still optional and wouldn't yield a difference
>> to a stable operation.
>>
>> Examples:
>>
>> dev-foo/bar:={:1.3= :1.4= :1.5=} OR dev-foo/bar(:= {:1.3= :1.4=
>> :1.5=}) renders := being an "any" operator meaningless since the
>> condition requires {:1.3= :1.4= :1.5=} to also be true.  It looks
>> insensible, but it's still algorithmically correct, and can be
>> interpreted by the package manager.
>
> Wrong. It means 'any OR 1.3 OR 1.4 ...'. Making 'any' no longer mean
> 'any' in this context is confusing.

Isn't that 'any AND (1.3 OR 1.4 OR 1.5)'?  Would that make sense to
have it the other way around instead?

And when I wrote that, I already had the idea of AND being the default
control operator, and spaces being optional.

> What about {:1.3/2 :1.3/3 :1.3=}?

Left to right.  If :1.3/2 yields true, then the whole condition is
valid, next is :1.3/3, then last :1.3=.  If all is false, then the
whole condition is false.

>> dev-foo/bar(:* :=) renders :* meaningless since := restricts any
>> installed runtime dependency's slot and subslot to be currently
>> available.  It's still algorithmically correct.
>
> 'any AND newest'? Why would you ever do that? The only purpose for :*
> is to disable warnings on missing slot specifications when package has
> multiple slots.

I hope you're only arguing against the misuse, and not about whether
it's feasible when it comes to the implementation.

But anyway, "newest" is not what's being said in ebuild(5):

":=     Indicates  that  any  slot value is acceptable. In addition,
for runtime dependencies, indicates that the package will break unless
a matching package with slot and sub-slot equal to the slot and
sub-slot of the best installed version at the time the package was
installed is available."

It's all about whether the currently installed runtime dependency's
current slot and sub-slot is available.  := in this case is simply
about checking that, and could only yield true or false.

Like I said I'm still new when it comes to these operators, but kindly
enlighten me so that we would know if := can be used as an independent
conditional expression or not.

Again, I don't agree with the misuse.  I just intend to give an example.

>> dev-foo/bar:={:1.3 :1.4 :1.5} OR dev-foo/bar(:= {:1.3 :1.4 :1.5})
>> implies that the currently installed package's slot and subslot should
>> be available and that the version of the slot should be 1.3, 1.4, or
>> 1.5.  The interpreter could read that condition checking from left to
>> right easily.  Is the currently installed package's slot and subslot
>> currently available?  If no, this condition renders false and the
>> currently installed package is invalid.  If yes, we follow the next
>> condition. Is the slot version any of 1.3, 1.4, or 1.5?  If yes, then
>> that condition yields true.
>
> I see a lot of added complexity here, for no benefit whatsoever.

No, it's not complex at all as everything would just be packaged in
one logical code.  I just had to explain detail by detail so I could
prove that it's doable.

The current check-if-some-specific-element-comes-before-or-after-another
which propagates everywhere in every context of every different type
of conditional element being checked makes things more complex.

>> > 4. Do we allow different ranges per slots?
>>
>> Seems possible like {:>=1.3 :<=1.5}.  Comparing subslots is also just
>> about grouping where in x/y, x is the major and y is the minor.  Major
>> versions are compared first, and minor versions are only compared if
>> major versions are equal.
>
> Slots are not numbers nor versions. You can't compare them.

Not that I really care about ranges for slots, but can you explain
why?  Is that somehow dependent to a current implementation?

>> > How do we combine various order of data?
>>
>> I need specific example/detail on that, or perhaps I already have that
>> answered above.
>
> dev-foo/bar(:1.6 {>=3.4 :5[foo]} ([bar] <3.7))

I'm yet to add opinion on allowing use flags to be used anywhere
besides outside a group and only once.  But that looks doable,
although seems more complicated to implement, or at least heavier,
maybe.  You should also correct that a bit:

dev-foo/bar(:1.6 {>=3.4 (:5 [foo])} ([bar] <3.7))

Also, enclosing [bar] and <3.7 inside () may not be necessary, unless
you'd want <3.7 to only compare against dev-foo/bar[bar] where you'll
have to use {![bar] <3.7}, or introduce a ternary operator like '[bar]
? <3.7 : true', which I think is not yet a necessary feature to
include.

>> >>Along with it, we should also drop the strict order of the slot,
>> >>version, and repo expressions (just change it to "recommended").  It
>> >>makes things more flexible and makes it easier for the parser to be
>> >>implemented.
>> >
>> > Problems:
>> >
>> > 1. This could result in fairly ambiguous variants with some syntaxes purposes.
>>
>> I think that would only apply to older versions of Portage that would
>> not recognize loose arrangement of conditions.  Can you give a
>> specific variant where would this become an issue?
>
> dev-foo/bar:1===3

Ok, just like everyone has already suggested grouping may be necessary.

dev-foo/bar:1=(==3)

>> > 2. This makes 'simple validation' harder. Strict order makes it possible to write a simple regular expression that validates that are elements are in place and correct, and are not repeated.
>>
>> It's quite the opposite.
>>
>> Before that 'simple validation', parsing would come first (unless
>> parsing comes along with (the only) validation itself), and parsing
>> itself [with/without the validation] has already become difficult due
>> to many conditions that one should come or could come before/after
>> another.  If every condition would just be elements with different
>> classes, it would be easier to do a validation.  You'll just need a
>> single loop with case statements for that, rather than have a tree of
>> if conditions.
>>
>> If there's another validation stage that's necessary to do after
>> parsing, the same holds true for it: just one single loop, and no
>> check if an element follows one after another.  Checking whether stuff
>> are repeated is still doable (if it still becomes necessary).
>>
>> I also hope you're not after grep-ability.  If not, just ignore this.
>> Grep/regex scanning itself is slow, and is a bit of a hack to me,
>> especially if it's used in parsing.  Not that I'm saying it's a bad
>> solution for doing validations, but it shouldn't be something to rely
>> upon when judging this.
>
> Yes, I am. In some cases, regexp is the only thing you have
> (e.g. in XSD). The major problem with current syntax is that you can't
> properly validate restrict="" in XSD because you'd have to
> backreference operator.

I don't know XSD, but it's good if we can improve it as well so we can innovate.

>> > 3. Do we allow multiple occurrences of the same type of element? I'm specifically thinking of multiple disjoint USE dependency blocks.
>>
>> I'm sorry but I'm not sure what you mean there.  I hope you can give an example.
>
> dev-foo/bar[foo][bar]

Again, I never really thought about allowing the [use] block to be
more re-arrangeable in the sense that it can be used more than once
and that it can be allowed inside condition blocks, but so far it
really looks doable, and we could drop the restrictions.  This would
be possible along with having everything changed to independent
conditional elements.

-- 
konsolebox