Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[Michał Górny]

Dnia 2015-09-19, o godz. 03:50:52
konsolebox <konsolebox@×××××.com> napisał(a):

> On Sat, Sep 19, 2015 at 2:23 AM, Michał Górny <mgorny@g.o> wrote:
> >
> >
> > Dnia 18 września 2015 11:32:15 CEST, konsolebox <konsolebox@×××××.com> napisał(a):
> >>This is what an ideal and simple versioning spec should look like to
> >>me.  (Not the form, but the concept).  I'm posting this here so it
> >>could be used as an added reference to anyone that would consider
> >>revising the current specification.
> >
> > The length of this mail itself proves that this is far from simple.
>
> Well that was called for yet still surprising.  I'm not sure how the
> length matters.  And imagine how longer it would have been if I used
> the 7 lexical algorithms of the current spec.

If you call something simple, make it simple. if it can't be
implemented simply, it's not simple. Simple as that.

> > And similarly to the current solution it's full of silly special cases and magical rules. If you really want something simple and clean, take a look at the scheme used by pkg-config and rpm.
>
> Silly because it uses a not-so-monolithic approach which is more
> convenient to implement and actually works?  What special cases or
> magical rules where you could find it more complex than the current
> spec?

It's silly because it shifts the existing terrible structure a bit
and doesn't really solve most of its issues. It's silly because you
still have a fair number of limitations which make parsing harder
rather than easier. It's silly because you still have to remember
the relation between 'alpha', 'beta', 'rc' and 'pre'. It's silly
because those magical suffixes never match what upstreams use.
And those are just a few sillinesses.

>  It's all about converting version strings to numerical values
> and comparing them from left to right.  And the idea on how things are
> mapped is just a model and doesn't necessarily need to be followed
> when making an implementation.  If you don't want to allow "version
> nodes" and only allow a single letter after the last version number of
> the base part, then you could do it.  How you convert 4a to a form you
> could use for comparison is up to you - maybe just a struct with two
> integral fields would suffice.  But the idea of (1) using four
> sections: base, stage, patch and revision, (2) converting each
> sections to arrays or lists of integral numbers or finite-sized data
> forms usable for comparisons, and (3) comparing them simply from left
> to right, is there.

I don't really understand what this paragraph was supposed to mean. Are
you saying that your spec is fun because it's fun?

> To add: comparing version strings in converted numerical forms is
> friendly to the processor.  You can also cache converted forms if you
> want.  On the other hand using a train of lexical algorithms that
> parses and compares strings at the same time is painful to implement
> and yields mixed-up code.  Separating parsing from comparing is
> convenient.
>
> And about pkg-config and rpm: I haven't thoroughly examined them yet,
> but you sure their implementation is applicable to Gentoo?  It might
> just turn simpler because it's more limited or strict.  Gentoo allows
> stages, patches and revisions and uses predefined prefixes.  Mine
> starts on a flexible approach where "version nodes" are allowed
> everywhere.

Then you should have. It is appreciated when people do some *research*
before throwing out random ideas on areas they have almost no idea of.

And to save you some time reading: the rpm implementation is simpler
and more flexible. It's free of stupidities like hardcoded suffix
lists or forced component ordering. Ordering (pre/post) is expressed
explicitly, and in many more cases you can avoid writing something
completely different than what upstream uses.

> If perhaps you mean to completely overhaul Gentoo's way of
> implementing package versions, I don't think that would work.

And is your change going to work? Because if you understood how ebuilds
work, you'd know you practically can't change versioning because you'd
immediately break compatibility between 'old' and 'new' ebuilds. This
isn't something that was designed to support changes in version scheme,
and changing that won't be anywhere close to easy. And if we ever agree
on doing that, we should go for a complete and useful solution rather
than some minor change with even smaller benefit.

> Just to remind you I'm presenting the idea, not the draft nor the
> implementation itself.  So don't pay too much attention on how it's
> made.  I think I should have given it a more abstract form, but this
> is just the first post.  I also hope you can give more specific or
> more elaborated criticizations about it, or perhaps give ideas on how
> it should be better implemented.

Also, you seem to have accidentally removed the mailing list from
To/CC.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>