1 |
On Sat, Sep 19, 2015 at 3:43 PM, konsolebox <konsolebox@×××××.com> wrote: |
2 |
> On Sat, Sep 19, 2015 at 5:05 AM, Michał Górny <mgorny@g.o> wrote: |
3 |
>> And to save you some time reading: the rpm implementation is simpler |
4 |
>> and more flexible. It's free of stupidities like hardcoded suffix |
5 |
>> lists or forced component ordering. Ordering (pre/post) is expressed |
6 |
>> explicitly, and in many more cases you can avoid writing something |
7 |
>> completely different than what upstream uses. |
8 |
> |
9 |
> I'm not sure what you mean, but you sure that adding the ability to |
10 |
> expression pre/post ordering does not make the algorithm even more |
11 |
> complicated? Note that you have to consider how you'd be able to |
12 |
> compare versions against other versions. |
13 |
> |
14 |
> That also sounds to me like you just have to add a _post stage with a |
15 |
> +1 value and it would be enough, rather than having a complete |
16 |
> overhaul. |
17 |
> |
18 |
> You say that you can express ordering explicitly: I find that it's |
19 |
> just the same problem you encounter when deciding what value to give |
20 |
> on _pre when encountering word versions like trial, devel, testing, |
21 |
> etc. |
22 |
> |
23 |
> I really think adding more commonly used suffixes should be enough. |
24 |
> |
25 |
> Btw, can you give a link on how the pre/post ordering is expressed? I |
26 |
> can't find any RPM versioning spec that describes how it's done. |
27 |
|
28 |
This just came to me. I think I may have got your idea, and I thank |
29 |
you for your input. We can actually allow multiple nodes on _pre and |
30 |
_post (and possibly other suffixes) so we can map custom suffixes as |
31 |
numbers. For example: "pkg-1.4.2_preX.Y.Z" That way we could allow |
32 |
maintainers to have their own custom levels for the suffixes. It |
33 |
would also not break compatibility with previous spec. And this would |
34 |
be conceptually more useful if we add _post as another stage with |
35 |
value of 1. |