[aur-general] Standardized CPAN Package Versions

[Xyne]

Justin Davis wrote:

> Could you give real-life examples? I have not seen a case where CPAN
> is confused by that. You seem to be saying that the packagers are at
> fault here but I always blamed the CPAN module authors. From what I
> remember, the biggest problem is when changing the number of digits.
> For example, if you go 0.8, 0.9, to 0.10. Ding. Bad. Switching from
> decimal to dotted decimal (multiple decimal points) also has problems.

You seem to think that I am saying that the versions on CPAN are wrong. I am
not. I am saying that Arch packagers do not understand the CPAN version schemes
and thus fail to correctly convert CPAN versions to Pacman package versions
($pkgver).

For example, a CPAN package could be update from 0.199 to 0.2. Pacman will
consider 0.199 to be the newer version, e.g.:

$ vercmp 0.199 0.2
1

A "force" flag would thus be required to update the package. The standardized
versions would be 0.199 and 0.200, which pacman can correctly compare.

The whole point of this is that CPAN has a very specific versioning scheme that
does not directly translate to Arch. It has syntax for major versions, minor
versions, alpha versions, etc. They is also a mixture of different syntax due
to legacy version strings that have not been updated. The provided script can
generate standardized versions using the "version" module which was designed
for this, and which is distributed as part of the Perl distribution and can
thus be considered official itself.


As the developer of tools to package CPAN packages for Pacman
automatically (Pacpan and Bauerbill), I can assure you that the the lack of
standardized versions in Arch poses a real-world problem. There is no way to
reliably generate PKGBUILDs with versioned dependencies as long as there
is no standard conversions.

The versions on CPAN can be directly compared using the version module. We must
format versions in a way that Pacman can compare, and that is what this script
does.

Regards,
Xyne