On 19 September 2015 at 10:09, konsolebox <konsole...@gmail.com> wrote: > 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
And both of those translations would be wrong. Math::BaseCnv's version is illegal even by Perl standards, but it uses it anyway. And that also means the is no way in Perl to declare you need 1.6.A6FG, any such dependency will either be treated as impossible to satisfy, or satisfiable by all versions, and there is no way to even *sort* versions that have invalid string components. Using a date based segment in Gentoo will allow us to package the component itself, but date order doesn't actually imply version order, they're just highly similar. Which basically means even *if* we normalise it somehow, any dependency we have on it in tree is just waiting to be wrong. Fortunately, cases like that are rare, and the associated yelling in bug reports are preferred avoided. And in the latter case, the "TRIAL" component is not actually part of the version, but is itself a release-grade specifier, and just so happens to be part of the *archive* name. This is because CPAN upstream are not "archive" oriented dependencies, but *module* oriented dependencies. And an archive can have >1 modules and they may not all have the same version. Hence, http://cpansearch.perl.org/src/MMCLERIC/Ubic-1.58_01-TRIAL/ Is actually just "1.58_01" + Alpha signifier Which here is redundant, because the "_" is an alpha signifier as well, and is deemed invisible in perl code. Alas, there's a horrible historical bug in version.pm that stupidly treats "_" in any version as significant. But either way, the right way to nomalise those versions is to elide the _ and '-TRIAL' parts. So the version is in fact: 1.5801 + ALPHA grade And then you get to the horror of the fact CPAN has *2* versioning schemes: MAJOR.FLOATINGPART DECIMAL.DECIMAL. Which means: 1.58.1 is less than 1.58 Why? Because 1.58.1 would be 1.058001 ( decimal to float conversion ) And 1.58 would be 1.580000 ( float not converted due to only 2 parts ) This is the horror of mixing too many version schemes into the same namespace. You get recurrent horrible gotchas that nobody intends on making, and makes repeatedly. The collective experience of Perl/CPAN and versions is that the toolchain operators wish we'd only ever had one version scheme, because there are just *so* *many* *ways* to confuse yourself when you switch from one scheme to another thinking its fine. And there are *so* *many* *ways* to royally cock it up, or do it the best way possible, and then have a downstream vendor not understand the reality of perl versions and then have downstream make a mess of it. For instance, downstreams without education are tend to see: 1.1, 1.10 , 1.2, 1.20 as: 1.1 , 1.2, 1.10, 1.20 When in reality, 1.10 = 1.10, and 1.2 == 1.20 In short: I'd rather Gentoo just had a tighter version scheme and good tooling to allow mapping from one-scheme to another on a case-by-case basis with forced normalised versions on the package itself. Perl Herd are doing just that because it greatly simplifies version interactions. -- Kent KENTNL - https://metacpan.org/author/KENTNL
