On Wed, 9 Nov 2016 14:32:33 +0800 konsolebox <konsole...@gmail.com> wrote:
> On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny <mgo...@gentoo.org> 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.
What about {:1.3/2 :1.3/3 :1.3=}?
> 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.
> dev-foo/bar{:* :=} renders := meaningless since :* would already be
> true, if it becomes false, := would still be false anyway. But it's
> still algorithmically correct. In many ways, the rule doesn't make
> sense at all since virtually is just boils down to be just about
> dev-foo/bar, but it's not an issue that would stop the implementation
> of the interpreter. And, it's also not something that would
> jeopardize how the package manager operates.
It's worse than meaningless. It requires the PM to record installed
slot for no reason whatsoever, since you allow it to switch to another
slot anyway.
> 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.
> > 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.
> I hope I understand you correctly.
>
> If you're talking about combining ranges of versions with slots, then
> yes it's possible. You just check every condition independently.
> It's pretty simple.
That's what I was asking for.
> > 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))
> >>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
> > 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.
> > 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]
--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
pgpu3vNe5ZTFZ.pgp
Description: OpenPGP digital signature
