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

[konsolebox]

On Sun, Sep 20, 2015 at 4:47 PM, Michał Górny <mgorny@g.o> wrote:
>> >>So what would pkg-1.4_alpha1_p20 look like if you convert it to a form
>> >>that uses ~?
>> >
>> > You shouldn't start with old gentoo version but with whatever upstream uses. The goal is that the scheme is really upstream friendly.
>> >
>> > So Python-3.5.0a2 would be 3.5.0~a2. We just add the tilde to indicate it's alpha-a and not post-version a.
>>
>> > Then, instead of full alpha/beta substitution we just strip the tilde.
>>
>> Strip the tilde?
>
> SRC_URI=".../Python-${PV/~/}.tar.xz"

Ok, although a version where the appended letter on the end of it does
not always imply alpha, so it doesn't always occur on most packages.

>> > So in your case, it could be 1.4~alpha1_p20, or 1.4~a1_20, or…
>>
>> Or just like my idea of using multiple nodes which is 1.4~a1.20?
>> Although I don't agree about concatenating the patch (_p) or another
>> custom suffix's value against the preceding suffix - because the
>> preceding suffix could actually have a dotted value in _alpha in which
>> case comparing the minor numbers would be ambiguous.
>>
>> >>Also what about if the package has a custom "newer than no suffix"
>> >>suffix used like pkg-1.4-sr5-p20?
>> >
>> > Well, sr would be used as letter version component but it shouldn't hurt.
>>
>> So we add `sr` as a known suffix, what about other possible suffixes?
>
> No, we don't. There are *no* known magical suffixes. 'sr' is just
> text version part, like 'a', 'b', 'c', 'za'...

So you get its value for comparison by base 26, base 27 or
lexicographic order level?

>> The point is, how would you compare custom suffixes when you don't
>> apply definite levels to them?  Which one would come before or after
>> another?  And comparing lexicographically does not always apply. Would
>> everyone have to convert them to presentable values where you could
>> calculate a number or compare in lexicographical order?
>
> You can't solve every single problem. Instead, you can apply simple
> and generic rules that could work in majority of cases, and be clearly
> changed in the remaining cases.

Well that would sound like your solution doesn't solve anything at
all.  You just added another version space where you can add
translated values of custom suffixes.  Forcing people to use
translated values even makes package versions less descriptive.
That's what's worth to be called as hard-coding.

>> > We could even extend this to allow multiple tildes and add another symbol that evaluates as higher than any version component.
>>
>> Yes, like adding _post?
>
> No, 'post' is string which again imposes limitation on upstream naming
> of versions. Use symbols as separators are symbols already.
>
>> This really sounds like it can be solved by allowing multiple version
>> nodes on _pre and _post just like what I said earlier.
>>
>> If you want you can have symbol versions of those but it would not be
>> necessary to actually remove the existing suffixes.
>
> You really can't think flexibly, can you? You always try to hardcode
> some strings, some arbitrary limitations because someone happened to
> implement Portage like this without too much thinking years ago.

I'm pretty sure I'm thinking flexible enough - as I also consider
compatibility despite also considering the use of symbols.  Maybe you
should ask yourself that instead?  Your method of doing things
generically would not apply if you can't have an algorithm that can
compare suffixes on their original form generically.  And so you also
cannot say that there is a difference between using a string or using
symbol if you can't place suffixes on them on their original form but
on their translated ones instead.