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

[konsolebox]

On Sat, Sep 19, 2015 at 5:05 AM, Michał Górny <mgorny@g.o> wrote:
> 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:
>> > 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

What issues?  My spec was not meant to solve issues which can't be
solved by any universal algorithm.  And it's not meant to add a
feature, but it can be used as a basis for one that would.

Perhaps provide your own spec on how you could solve those issues then
let's see if your point is correct.

> It's silly because you
> still have a fair number of limitations which make parsing harder
> rather than easier.

What limitations specifically?  I'm not sure why you'd find it harder,
as compared to the current spec.  And it's not even hard generally.

> It's silly because you still have to remember
> the relation between 'alpha', 'beta', 'rc' and 'pre'.

What kind of implementation would you have where you don't remember
those?  Do you imply to completely avoid them?  How would you get to
compare versions having alpha, beta, pre and rc then?  Do you mean to
use another library to get each one's priority?  Wouldn't that still
need to be specified in the spec?

> It's silly
> because those magical suffixes never match what upstreams use.
> And those are just a few sillinesses.

Yeah unfortunately there could be just unlimited number of possible
suffixes and unlimited ways on how they could be used so the best
thing you could do is provide what's commonly used and just let the
ebuild maintainer decide how he could work around with those suffixes
so he could present it well on the ebuild.

>> 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.

It's not a random idea as it only intends to simplify the current
spec, not drastically change it.  And it doesn't really matter for me
to thoroughly understand them if you only intend to completely change
Gentoo's packaging system to be like them.  It's not my spec's concern
to change things that way.

> 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.

I'm not sure what you mean, but you sure that adding the ability to
expression pre/post ordering does not make the algorithm even more
complicated?  Note that you have to consider how you'd be able to
compare versions against other versions.

That also sounds to me like you just have to add a _post stage with a
+1 value and it would be enough, rather than having a complete
overhaul.

You say that you can express ordering explicitly: I find that it's
just the same problem you encounter when deciding what value to give
on _pre when encountering word versions like trial, devel, testing,
etc.

I really think adding more commonly used suffixes should be enough.

Btw, can you give a link on how the pre/post ordering is expressed?  I
can't find any RPM versioning spec that describes how it's done.

>> 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.

Except that mine is unlikely to break compatibility with current
packages.  You have issues against the very foundations of the current
implementation, but that's not really about my spec per se.  You seem
to be barking at the wrong tree and I don't think that would help.

> 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.

Unfortunately doing an overhaul may never happen unless you create
Gentoo 2.0 where a mirror of every package would work on it.  So
simplifying it first (and optionally enhancing without breaking) could
be a good choice whether an overhaul happens later or not.