Add a new perl.prov script to generate normalized module versions

[perlpunk]

Background

I'm the current maintainer of https://github.com/openSUSE/cpanspec and I do automatic updates to devel:languages:perl with it.

Perl module versions are decimal versions, and semantically split in triplets.

CPAN       --> Normalized, semantical meaning from perl's point of view
0.7        --> 0.700.0
0.71       --> 0.71.0
0.70       --> 0.70.0
0.07       --> 0.70.0
0.007      --> 0.7.0
1.20230726 --> 1.202.307.260

Currently, perl.prov takes the module versions literally, which can lead to false / broken dependencies if the number of decimals for a module version changes.
E.g. a very common thing is a module with the current version 1.29 (which is semantically 1.290.0) that releases 1.3 (1.300.0) as the next version.
Taking the 1.29 and 1.3 literally in the rpm, 1.3 would be lower than 1.29.

We usually fix that manually, but we have 3200 perl modules in devel:languages:perl and 1400 in Factory.

The correct way would be to use

version->parse($cpan_version)->normal

However, we can't just fix the existing perl.prov because we cannot guarantee that all packages will be rebuilt at once across all repositories. There needs to be a transition period also.

Also other users of rpm maybe don't want that new behaviour.

Proposal

So I created a new script besides perl.prov, perl.prov.normalize.

It would be good if I could actually reuse most of it's code, maybe even simply call perl.prov and then manipulate the output.

But for this frst draft I wanted to get your feedback if such a PR is welcome or if it should be done in a new package outside of rpm.

I could then use this script in the spec files of new perl module releases. Until then there will be a transition period where I might generate Provides lines in the spec file additionally to the current perl.prov, which would guarantee that we don't get unresolvables.

For the detailed background see: openSUSE/cpanspec#47 cpanspec is the script which we use to generate the spec files.

[stoecker]

See also #2609 for a patch to the existing tool.

[pmatilai]

But for this first draft I wanted to get your feedback if such a PR is welcome or if it should be done in a new package outside of rpm.

We'd actually like the Perl generators to move to a new package outside rpm entirely. This has been done for eg Python already, but Perl has lingered on despite eg Fedora not using the version we ship at all. All we need is maintainer(s) for that package, we'd be happy to host it here under rpm-software-management org.

[perlpunk]

@pmatilai thanks.
I would like to start a new package then and work on it together with @stoecker
Should I create a new repo and then request to transfer it to this org?

[pmatilai]

We can do that, or just create the repo in this organization to begin with. Either way, just file the request at https://github.com/rpm-software-management/org-admin

[Conan-Kudo]

cc: @ppisar

[ppisar]

I do not maintain perl in Fedora. CCing current maintainer, @jplesnik.

[jplesnik]

Fedora has perl-generator package since 2014.
It contains perl.req, perl.prov and fileattrs based on rpm-4.11.2.

Over the years, there have been some updates in dependency detection and bug fixes issues reported in Fedora.
We also added some changes related to Fedora's workflow.

List of the changes, you could find here.

[perlpunk]

I created https://github.com/perlpunk/rpm-perl
For now it just contains copies of the original perl files.
Which license should I use?

[stoecker]

Which license should I use?

Same as rpm package has now, as you copy code. GPL-2.0-or-later according to the files itself.

[pmatilai]

I created https://github.com/perlpunk/rpm-perl
For now it just contains copies of the original perl files.

I'd recommend copying the history too, there's over 20 years of history in there.

The name of the repo is up to you of course, but just for reference the python counterpart is named thus: https://github.com/rpm-software-management/python-rpm-packaging
The nice thing about that is that there's no confusing it with the language bindings.

[dmnks]

OK, let's do the splitting part ourselves first, via #2873. This PR should then be migrated to the new repo once it exists. I'll close it here and add a note to the splitting ticket.