| 1 |
On Sat, Sep 19, 2015 at 10:54 PM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> Here's my old proposal: https://bugs.gentoo.org/show_bug.cgi?id=526456 |
| 3 |
> |
| 4 |
> Dnia 19 września 2015 14:59:35 CEST, konsolebox <konsolebox@×××××.com> napisał(a): |
| 5 |
>>On Sat, Sep 19, 2015 at 6:55 PM, Michał Górny <mgorny@g.o> |
| 6 |
>>wrote: |
| 7 |
>>> Dnia 19 września 2015 12:27:32 CEST, konsolebox |
| 8 |
>><konsolebox@×××××.com> napisał(a): |
| 9 |
>>>>On Sat, Sep 19, 2015 at 4:01 PM, Michał Górny <mgorny@g.o> |
| 10 |
>>>>wrote: |
| 11 |
>>> Which one is simpler: |
| 12 |
>>> |
| 13 |
>>> 1. _pre, _alpha, _beta, _rc... is earlier than no suffix, _p is newer |
| 14 |
>>than no suffix, |
| 15 |
>>> |
| 16 |
>>> 2. ~ is earlier than no suffix? |
| 17 |
>>> |
| 18 |
>> |
| 19 |
>>Ok I have to admit that no. 2 is simpler. It's less descriptive and |
| 20 |
>>requires general or specific guidelines on representing common |
| 21 |
>>suffixes, but it allows more flexibility. I actually had the idea |
| 22 |
>>earlier of using _pre but using a symbol is more appropriate. Besides |
| 23 |
>>_pre already has a position which is > _beta and < _rc. |
| 24 |
>> |
| 25 |
>>So what would pkg-1.4_alpha1_p20 look like if you convert it to a form |
| 26 |
>>that uses ~? |
| 27 |
> |
| 28 |
> You shouldn't start with old gentoo version but with whatever upstream uses. The goal is that the scheme is really upstream friendly. |
| 29 |
> |
| 30 |
> 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. |
| 31 |
|
| 32 |
> Then, instead of full alpha/beta substitution we just strip the tilde. |
| 33 |
|
| 34 |
Strip the tilde? |
| 35 |
|
| 36 |
> So in your case, it could be 1.4~alpha1_p20, or 1.4~a1_20, or… |
| 37 |
|
| 38 |
Or just like my idea of using multiple nodes which is 1.4~a1.20? |
| 39 |
Although I don't agree about concatenating the patch (_p) or another |
| 40 |
custom suffix's value against the preceding suffix - because the |
| 41 |
preceding suffix could actually have a dotted value in _alpha in which |
| 42 |
case comparing the minor numbers would be ambiguous. |
| 43 |
|
| 44 |
>>Also what about if the package has a custom "newer than no suffix" |
| 45 |
>>suffix used like pkg-1.4-sr5-p20? |
| 46 |
> |
| 47 |
> Well, sr would be used as letter version component but it shouldn't hurt. |
| 48 |
|
| 49 |
So we add `sr` as a known suffix, what about other possible suffixes? |
| 50 |
The point is, how would you compare custom suffixes when you don't |
| 51 |
apply definite levels to them? Which one would come before or after |
| 52 |
another? And comparing lexicographically does not always apply. Would |
| 53 |
everyone have to convert them to presentable values where you could |
| 54 |
calculate a number or compare in lexicographical order? |
| 55 |
|
| 56 |
> We could even extend this to allow multiple tildes and add another symbol that evaluates as higher than any version component. |
| 57 |
|
| 58 |
Yes, like adding _post? |
| 59 |
|
| 60 |
This really sounds like it can be solved by allowing multiple version |
| 61 |
nodes on _pre and _post just like what I said earlier. |
| 62 |
|
| 63 |
If you want you can have symbol versions of those but it would not be |
| 64 |
necessary to actually remove the existing suffixes. |
Archives