[aur-general] Standardized CPAN Package Versions

[Justin Davis]

On Sun, Feb 6, 2011 at 8:36 PM, Xyne <xyne at 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