On Sat, Sep 19, 2015 at 4:11 AM, Vladimir Smirnov <ci...@gentoo.org> wrote: > On Fri, 18 Sep 2015 23:16:43 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> If you avoid trying to adopt versioning practices which are far from >> practical and very far from common it is (as proven by the example >> code). The workaround for such rare cases should be done on the >> ebuild's version. >> > > Just have a look on CPAN module versions. You'll see that it's much more > common than you think. Just few examples: > http://search.cpan.org/~pip/Math-BaseCnv-1.6.A6FGHKE/ > http://cpansearch.perl.org/src/MMCLERIC/Ubic-1.58_01-TRIAL/ > > And so on. There are much more than that. Also strange version translations, > where new release may just start to use new version scheme. And so on, and so > on.
And the ambiguous part of the current spec which interprets numbers starting with 0 differently didn't really help much in solving problems in adapting those irregular versioning schemes. That is why it's better to just implement a more simple and consistent universal approach and keep the decisions on how those irregular versions should be represented in ebuilds to the ebuild maintainers. As for A6FGHKE and TRIAL, it's impossible to tell their actual level values so even if we choose to map them lexicographically, we would still not be able to use a universal algorithm that could tell how it affects the base version (just like how stages affects it) and how it compares with other values as well. So it would still be up to the maintainer how he would represent the versions on ebuilds. One could do: Math-BaseCnv-1.6.20YYMMDD and Ubic-1.58.01.20YYMMDD or Ubic-1.58.01_pre20YYMMDD
