[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: Speaking about debian-perl to conferences



On Mon, Mar 3, 2008 at 10:27 PM, gregor herrmann
<gregor+debian@comodo.priv.at> wrote:
>  > >   (0.2200-3)      libdbd-csv-perl
>  >     Is actually 0.22 on CPAN, where is the additional 00 from?
>
>  Added by Debian; the problem is that the history as seen on
>  http://search.cpan.org/dist/DBD-CSV/ was
>  0.1030
>  0.2001
>  0.2002
>  0.21
>  0.22
>
>  For CPAN 0.21 is probably greater than 0.2002, for Debian 21 < 2002.
>  By adding the trailing zeros we get our math right again :)

If I understand that means that for Debian it is better to keep the old but
strange version number than to move (once!) to the saner one with only
two digits after the dot and then keep the new numbering.

Isn't there a way for Debian to somehow follow the module to its new version
numbering and hope it will stick to it?


>  > >   (0.2808.01-1)   libmodule-build-perl                      0.2808
>  >     Where was the additional 01 taken
>  >     from ? Was that the 0.2808_01 release?
>
>  Exactly, the underline is converted to a dot because underlines are
>  not allowed in Debian version numbers.
>  No big deal.

AFAIK that means it is a developer version that should not be distributed.
So I think should not get into the Debian repository.

>
>
>  > >   (0.06.1b-5)     libpdf-create-perl
>  > Currently 0.08 on CPAN
>
>  That's another funny case -- CPAN has different releases then
>  sourceforge for this same module :/
>  I guess we should track both ...
>  (http://sourceforge.net/projects/perl-pdf/)

I would think better to track only CPAN. Those should be the
"official" releases.



>  > In any case there is already a CPANTS kwalitee metric for proper version number
>  > http://cpants.perl.org/kwalitee.html but all the mentioned modules
>  > passed the test.
>  > So maybe the has_proper_version on CPANTS should be stricter.
>
>  From a Debian point of view the versions are all fine -- as long they
>  stick to the same scheme for a given module; what's difficult for our
>  sorting algorithms are modules that change from x.yyyy to x.yy or
>  from m.nnnn to m.nn.nn or similar.

OK, so I don't have a selling point here :-)
I better go to sleep then.

>  If you're interested in the details, the sorting algorithm is
>  explained at
>  http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

thanks
   Gabor


Reply to: