action #164314
openopenQA Project - coordination #154768: [saga][epic][ux] State-of-art user experience for openQA
openQA Project - coordination #168127: [epic] Up-to-date Perl stack
devel:languages:perl Module version normalizing size:M
0%
Description
Motivation¶
Comparison between perl package versions in SUSE should work without having to manually fix the number of decimal digits sometimes.
Details: https://github.com/openSUSE/cpanspec/issues/47
This issue is mostly to track my work on that.
Steps¶
A: d:l:p only¶
Convert all modules that are only in devel:languages:perl, but not in Factory. Since those are not critical, that can take multiple days, in between there might be some unresolvables.
B: Factory¶
- Update all "Provides" data d:l:p modules that are in Factory.
- perl-Foo-Bar
Version: 1.23
becomesVersion: 1.230.0
,Provides: perl(Foo::Bar) 1.230.0
, butRequires: perl(Foo::Bar) >= 1.23
in other modules won't be updated yet. - After all updates from the previous step landed in Factory/Tumleweed, the
Requires
lines can be updated
- perl-Foo-Bar
C: Core modules¶
Think about a strategy for core modules. E.g. there is Module::CoreList 5.20240720
and CPAN 2.36
.
If we would update the perl.prov script for the perl
package to produce normalized versions, it would report:
Provides: perl(Module::CoreList) 5.202.407.20
Provides: perl(CPAN) 2.360.0
If we update all Requires
in d:l:p, we would have for example:
Requires: perl(Module::CoreList) >= 5.202.301.01
Requires: perl(CPAN) >= 2.310.0
That works for the perl package in d:l:p and in Factory. But in Leap we have an older perl version, so the second line will be unresolvable.
Either perl.prov has to be updated for Leap as well at some point, but then older modules in Leap will have the old require lines, e.g. Requires: perl(Module::CoreList) >= 520230101
and that will fail.
For now I keep all modules that are in perl core 5.40 in their original format. Of course that might need updates with every new perl version, when modules are added or removed from the core.
It would be useful if we could have a condition on the perl version in the spec, e.g.
%if perl >= 5.40.0
Requires: perl(CPAN) >= 2.310.0
%else
Requires: perl(CPAN) >= 2.31
%endif
Or depending on the suse_version might also work. For that I would need reliable information on when perl 5.40 will land in Leap.
Consider OS version checking in spec files on Perl core modules.
Updated by tinita 4 months ago
- Description updated (diff)
I'm currently in step A, d:l:p only. I have converted all modules A-F, around 450. (I left a few ones I couldn't figure out, but that's fine).
My process is partially automated.
It's still taking quite long because
- The diff can be huge because some of the modules haven't been updated for many years (going back up to 17 years), so I have to look at each diff closely to spot anything that my update might remove
- There are still a lot of modules that have manual edits like patches or requirements that are not in the cpanspec.yml, so regenerating the spec will lose it, so I have to add it.
The good thing is, after that everything will be in cpanspec.yml (1), so if I need to regenerate again, the process can be more automated.
(1) Regarding having all changes in cpanspec.yml: We talked at the Perl Toolchain Summit about sharing patches and other things that CPAN modules miss in a common repository, that folks from Fedora, Debian, NixOS, SUSE and others could use.
Updated by tinita 3 months ago ยท Edited
I just finished step A, converting all non-factory modules.
During that, I had to make a few fixes in cpanspec
for some edge cases. Also I had to leave about 80 modules unchanged because:
- some of them are dual life modules, that means they are also in core, and there I will keep the version like it is for now
- generating a new spec would remove certain manual changes from the spec, and it would take time to find out what to put into cpanspec.yml to not having to manually edit the spec file after generating
The next step will hopefully a bit faster. There are less modules to convert, and I suppose the modules are better maintained and always have a proper license.