On Wed, 9 Nov 2016 18:17:25 +0800 konsolebox <konsole...@gmail.com> wrote:
> On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny <mgo...@gentoo.org> wrote:
> > On Wed, 9 Nov 2016 14:32:33 +0800
> > konsolebox <konsole...@gmail.com> wrote:
> >> 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?
I'm sorry, I misread that.
> >> 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.
> >> 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).
> >> > 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?
Slots are free-form strings by design. This has its uses, including
named slots ('stable', 'testing'...), subslots representing SONAMEs of
multiple libraries ('liba0-libb4')...
> >> > 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]
?
> > 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.
> >> > 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 || ().
--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
pgpjY9Dp8BlOx.pgp
Description: OpenPGP digital signature
