On Sun, Feb 6, 2011 at 8:36 PM, Xyne <xyne@archlinux.ca> wrote:
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).
You said a version comparison done by "CPAN" is wrong here:
To give an example, CPAN considers "1.15" to be a later version than "1.23.0", ...
You seem to be lumping the version module and CPAN together. This is what is confusing in your message. You mentioned a CPAN version scheme but there is no such thing. CPAN authors are free to version things like crazy, however they like. I can upload a distribution file to the CPAN with a version that is less than my last version. CPAN will politely notify me of my mistake and release the distribution anyways.
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.
CPAN has no specific versioning scheme at all. Many versions of distributions on CPAN follow the simple decimal format like 1.23. Some have the dotted-decimal format of 1.23.45 etc. Others have dates for versions like 20101234. Sometimes new releases of a distribution change from one scheme to the next. It's chaos. The version module has in the past been unreliable. It is bloated and even changes behavior. This is mentioned in my previous email. The old behavior used the 'qv' function while the new behavior uses the 'parse' class method. Yes, they give different results. I even tried using the version module for my module's $VERSION, which ended up prefixing the version in my distribution file with a 'v'. Annoying.
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.
Certainly you know by now, I create a similar tool with my CPANPLUS::Dist::Arch module. You know I have seen the same problems. How about we slow down a little and work together to try to fix this. A good first step would be to clearly define the problem. There is also plenty of test data available, the entire CPAN and Backpan with thousands of versions to play with. What Kaiting says is absolutely correct. Why not test this out and gather some data before asking everyone to start using it? I would have to see for myself whether this worked for a majority of cases before adopting it. Before that, clearly defining the problem in a document with some real data would be helpful. Then some scripts could be made to gather versions and comparisons. We could even work with the perl community to try to clean up their versions or flag the offensive versions. There is also the problem which stopped me from probing further on this subject. If some packages do not use the same method as I do in normalizing versions than it is all for naught. There could be two packages with different version strings, representative of the same original CPAN distribution, which pacman evaluates differently. -- -Justin