I wrote a blog post thoroughly explaining Perl module versions and agree with the assessment and suggested method presented (though I have no comment on the remedy). http://blogs.perl.org/users/grinnz/2018/04/a-guide-to-versions-in-perl.html -Dan On Thu, Aug 6, 2020, 1:09 PM Tina Müller <timueller@xxxxxxx> wrote: > Hi, > > I'm working at SUSE, and for about a year I have been in charge of updating > the CPAN modules in SUSE Open Build Service: > https://build.opensuse.org/project/show/devel:languages:perl > > This is half automated. The spec file is generated with the cpanspec > script, > and we manually look over the diff and then request the package to be > updated. > > I would like to make a suggestion and will explain the problems in detail, > so > that we are all on the same page. > > # Status Quo > > As you probably know, the versioning scheme of Perl modules differs from > rpm. > For perl, the versions are decimal, so it can happen that for a given > module A > versions 0.23 and 0.3 are released. The latter one is higher for perl. > Semantically, 0.23 is 0.230.0 and 0.3 is 0.300.0, when correctly > translated to a > rpm like version. > > You can also use versions like 1.2.3 in perl. In that case, they are > already > semantically equal to rpm like versions. The majority of perl modules > still uses > decimal versions, though. > > Many distributions including openSUSE and Fedora are just taking over the > perl > module version literally. > > This sometimes leads to problems, for example if module B requires module > A: > > Requires: perl(A) >= 0.23 > > When module A is uploaded with version 0.3, this will result in an > unresolvable > dependency. > > In those cases we have to manually fix the requirement. > Granted, this doesn't happen very often, but when, it's annoying. > > There might also be cases where it is the other way around, e.g. module A > has versions 0.02 and 0.1. 0.02 is just the same as 0.2 in rpm. > > Module B has: > > Requires: perl(A) >= 0.1 > > If module A is still at version 0.02, the dependency will be satisfied, > because 0.1 is lower in rpm than 0.02. > But that is wrong. In this case we don't see the mistake though. > > Here is a discussion about this that started when I posted my Howto > for creating a CPAN module with correct Metadata: > https://github.com/perlpunk/perl5-module-meta/issues/5 > > # Alternative > > The correct way to translate the versions for the spec would be: > > perl -wE'say version->parse($ARGV[0])->normal;' 0.23 > v0.230.0 > > and then we just have to cut off the 'v' at the beginning. > This should work correctly for all module versions, and it is the right > thing > to do. > We wouldn't need any manual handling anymore. > > # Problem > > As it is impossible to just change all modules in the distributions at the > same > time, we need backwards compatibility. > > # Proposal > > I discussed this on IRC #opensuse-factory. A suggestion came up how to > avoid > having to be backward compatible. > > The versions of each module inside a CPAN distribution are usually > generated > at build time with perl.prov > ( > https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.prov > ). > > Some distributions also use > https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.req > but openSUSE doesn't. The dependencies are extracted at the time when the > spec > file is generated. > > We could add a new capability additionally to perl(). Maybe cpan(). This > can > use the new versioning scheme. > The packages could be built with both capabilities. > As soon as all packages are rebuilt, we can start to adjust the Requires > lines to use the new capability. > > This part is actually pretty easy and shouldn't require much work. Please > correct me if I'm wrong. > > However, there is also the package version, and instead of > > Require: perl(A::B) >= x.y > > one can do > > Require: perl-A-B >= x.y > > so for those package versions we need backward compatibility. > > My idea is to take a snapshot of all CPAN modules we have in our repository > and save the package id and the version. > > The migration strategy to the new versioning scheme would be: > > All modulues having 1, 2 or 3 decimals can update to the new scheme > whenever > a new version is uploaded. > > Let's take module A as the example again. The current (CPAN) version would > be > 0.23. > > When a new version 0.3 is uploaded, we compare the version for A to our > saved > version 0.23. If it is (decimally) higher, we use the new scheme: 0.300.0. > Same thing for other modules requiring A (although we mostly use capability > requirements anyway). > > For all modules having 4 or more decimals, the switch to the version scheme > has to wait until the major version is updated (which might be never for > some > modules). > E.g. module B has 1.201703. Then we have to wait until the major version is > incremented to 2. > > I made some statistics for our devel:languages:perl repo to see how many > decimals the packages have: > > a: 21 > a.b: 120 > a.bb: 2045 > a.bbb: 497 > a.bbbb: 100 > a.bbbbb: 25 > a.bbbbbb: 165 > a.bbbbbbb+: 11 > a.b.c+: 129 > > So the large majority uses 3 or less decimals. > > I know the second part is a lot of work, and it feels it comes a bit too > late, considered how long perl has been around. OTOH perl will probably > stay around for a while. > > What do you think? Do you think it's worth it? Are there any flaws in my > migration strategy? Or do you have alternative suggestions? > > Would be glad to hear from you. > > cheers, > tina > > _______________________________________________ > perl-devel mailing list -- perl-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to perl-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/perl-devel@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ perl-devel mailing list -- perl-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to perl-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@xxxxxxxxxxxxxxxxxxxxxxx
