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