6:45 a.m.
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