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
