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

[konsolebox]

On Wed, Nov 9, 2016 at 7:12 PM, Michał Górny <mgorny@g.o> wrote:
>> On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny <mgorny@g.o> wrote:
>> >> 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."
>
> I meant newest installed.

Ok, so do you think := can be used anywhere just like any other
conditional element?

>> >> 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.
>
> I think you're forgetting the most important point here. Dependency
> specifications are not only used to check some installed package for
> match. They also need to make it possible to semi-reasonably pull
> in additional packages that could be used to satisfy the dependency.
>
> The more complex conditions you allow, the harder the task becomes for
> the PM and the slower Portage becomes (because it needs to consider
> more variants of a possible solution).

I still need to confirm things in a more technical manner, so I can't
make a reply about that for now.

> Slots are free-form strings by design. This has its uses, including
> named slots ('stable', 'testing'...), subslots representing SONAMEs of
> multiple libraries ('liba0-libb4')...

I see.

>> >> > 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))
>
> Why are you forcing whitespace in some contexts and not in other
> contexts? Does this mean the common case would look like:
>
>   dev-foo/bar >= 1.4 :1.6 [bar]
>
> ?

Sorry, I misguessed.  I thought you wanted :5 and [foo] to be used
together; that both items should be true.

>> > 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.
>
> Err, are you talking Gentoo is supposed to request full FSM to be
> included in XML Schema? I honestly doubt standard bodies will seriously
> consider that.

I see. I can't comment much on that unfortunately.

>> >> > 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.
>
> 'I never really thought' is the core problem. When you want to change
> PMS, you really have to think about everything. Otherwise, you end up
> with screwups like := in || ().

Well I'm also the type who tries to consider everything, but this was
more of a blind spot, and a little bit of a different context
that you can't think about quickly.

I also just thought that everyone would feel conservative towards it,
so I was just being careful, but I actually like the idea of including
[use] blocks in the change.

-- 
konsolebox