On Sat, Sep 19, 2015 at 3:43 PM, konsolebox <konsole...@gmail.com> wrote: > On Sat, Sep 19, 2015 at 5:05 AM, Michał Górny <mgo...@gentoo.org> wrote: >> 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.
This just came to me. I think I may have got your idea, and I thank you for your input. We can actually allow multiple nodes on _pre and _post (and possibly other suffixes) so we can map custom suffixes as numbers. For example: "pkg-1.4.2_preX.Y.Z" That way we could allow maintainers to have their own custom levels for the suffixes. It would also not break compatibility with previous spec. And this would be conceptually more useful if we add _post as another stage with value of 1.
