Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[Raymond Jennings]

Gentoo is a distribution that incorporates heterogeneous software packages,
each of which may have their own versioning scheme.

We kinda have to treat the upstream version as an opaque blob because of
this.

Maybe I'm missing something but I don't think it's ok to screw with
upstream supplied version numbers.  Sorting them is fine but to me they
appear best treated as whole atoms that shouldn't be picked apart.

On Fri, Sep 18, 2015 at 6:02 PM, Kent Fredric <kentfredric@×××××.com> wrote:

> On 19 September 2015 at 10:09, konsolebox <konsolebox@×××××.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
>
>