On Thu, Aug 06, 2020 at 07:09:37PM +0200, Tina Müller wrote: > I'm working at SUSE, [...] > As you probably know, the versioning scheme of Perl modules differs from rpm. We have the same issue in Fedora. We had a discussion about it in the past, and the result was that while few packagers wanted to fix it, most of them rejected the change, therefore Fedora did not move. I saw that Gentoo managed it. Probably because of fewer interested people. > 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. At that time I implemented the conversion in pure Perl <https://repo.or.cz/Fedora-VSP.git/blob/HEAD:/lib/Fedora/VSP.pm> and as a C library and a program <https://ppisar.fedorapeople.org/fvsp/>. $ fvsp -l 0.23 0.230.0 The motivation was keep rpm tool free from Perl and support bootstrapping Perl when XS version module implementation is binary incompatible with the new Perl. Have you thought about an underscore character in the version string? While modern version module ignores the underscore (0.1_2 is 0.12), there used to be a guide line that the underscore designates a prerelease (0.1_2 is the second prerelease of 0.1) and thus should be ordered before the stable release (0.1). I remember I saw such releases on CPAN. I came to a conclusion that there is no correct (in the meaning of compatibility) way of handling the undersore. Maybe it's not a problem anymore. > # Problem > > As it is impossible to just change all modules in the distributions at the same > time, we need backwards compatibility. > It depends on how you understand the "distribution". If you mean only the latest version of the distribution (e.g. Fedora 33 in constrast to Fedora 32), then Fedora is able to switch the versioning for all packages delivered by Fedora in one week. (On the assumption that Fedora people agree on it). > # 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. > Please note that in Fedora we do not use any of them. We moved them from RPM tool to an independent tool maintained by Fedora Perl folks. I want to say that I value that you share your opinion with Fedora people, but whatever changes you do in upstream RPM, it won't have any direct effect on packaging of Perl code in Fedora. > 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. > That's a nice plan. Would you remove perl() at the end? Or would you mirror cpan() to perl() and then remove cpan() in order to get back to perl() name space. I want to say that cpan() is not the best name, because not all Perl code comes from CPAN. I don't know packaging in SuSE. But in Fedora we have a problem with legacy. Some packagers want to share one spec file among multiple Fedora (or even RHEL) releases. That means once you rewrite Requires from the decimal perl() to the normalized cpan(), the spec files become incompatible with the older distributions. And that was the fact that shut down my previous attempt in Fedora. (I proposed to hide the difference in a %perl_v() RPM macro <https://ppisar.fedorapeople.org/perlmacros2/src/macros.perl2>, but that was also opposed as making the packaging less legible. In general there was opposition to any change that would require packaging in any new way. But some time passed, maybe the mood has changed since then. I can try it again.) > 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. > In Fedora we banned depending on Perl package names for the purpose of installing the Perl modules. Packagers must use perl() for that purpose. As for normalizing RPM package versions, you can bump RPM Epoch value. > 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. > Waiting on that would be infinite in some cases. If you ever want to finish the transition, I would recommend you employing RPM Epoch value. Honestly in Fedora, where we use versinoned dependenices on modules heavily, but we do not use versioned dependenices on RPM packages, I would rewrite Perl module versions without employing the RPM epoch as an internal Perl afair. And for RPM package versions, whose values must be monotonic across Fedora releases, I would either bump the epoch, or keep them non-normalized (dependening on a distribution-wide consensus). An automatic monitoring of new upstream releases could work as a good incentive for packagers who were reluctant to normalize the package version. > 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. > That means that a large majority of the versions get longer. E.g. 0.23 becomes 0.230.0. Have you considered triming the trailing ".0" part? If you have a mix of the decimal and normalized versions in a distribution, then seeing a dot-dot version makes you aware that it's a normalized version. But when you have all the versions normalized, having most of them with ".0" looks superfluous. But maybe it's only my norrow-minded Perl-centric point of view. Maybe other people need the dot-dot clue to be able to understand the versions. > 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? > I'm actually glad that it's not only me who has this problem. I got an impression that most pople do not care and those who care, do not want any improvment. So actually if something happens in SuSE, it means there could be a time to improve Fedora too. I'm curious what resolution SuSE will choose. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
