On 30 June 2012 00:13, Corentin Chary <email@example.com> wrote:
> It's already the case:
> but my mangling functions are probably broken in some cases. If
> somebody with a better knowledge of CPAN versionning scheme could fix
> them it would be great !
The thing is there isn't a true versioning scheme for CPAN, just a
defacto one agreed upon by the community. There are several
versioning schemes in employ, but the mechanics of each are rather
messy, and then you have some lovely fellow like pip come along and
put garbage in their version, and we have to handle it manually.
For the most part though, people use "sensible" versions of a very few
basic varieties, and we downstream normalise these smattering of
varieties into a single form to make everything nice and tidy. Its
still a work in progress migrating older ebuilds to our new
normalisation scheme, but its getting there.
And we do have a tool that will convert /most/ CPAN versions into
portage versions, which works as long as upstream are sane:
Which relies on another perl module 'version.pm' (
virtual/perl-version ) which handles most the real dirty work of
normalising things, and we just do a bit of post-processing of that to
make it nicer for us ( mostly stripping leading 0's in digit groups,
and mapping the upstream 'developer release' hints ( ie: -TRIAL or
_01 components ) to the _rc suffix.
If you wanted to you could call that script, or delve into the guts of
it and version.pm and try understand how it works, but you could be
there a while.
But we're unfortunately going to *always* need a way to correct
versions, because upstream occasionally produce bogus nonsense
versions that don't even make sense. ( ie: making versions go
backwards and expect it to work, but it does, because the cpan indexer
takes whatever was most recently uploaded ... or something like that.
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"