action #164314
openopenQA Project (public) - coordination #154768: [saga][epic][ux] State-of-art user experience for openQA
openQA Project (public) - 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 8 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 7 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.
Updated by tinita 3 months ago
- Copied to action #175323: [devel:languages:perl] Fix autosetup handling in cpanspec size:S added
Updated by tinita about 2 months ago
- Target version changed from Tools - Next to Ready
Updated by tinita about 2 months ago
- Status changed from In Progress to Workable
Working on Task B now: I updated maybe about 50 modules so far, getting up to speed. I have to be a bit more careful to not produce broken builds or create unresolvables.
Setting back to workable as I only do this a few hours per day.
Updated by tinita about 2 months ago
There is https://github.com/rpm-software-management/perl-rpm-packaging which now can be used like this:
%define %__perllib_provides %{_rpmconfigdir}/perl.prov --normalversion
However, I tried it out and found there was a little mistake in the script which I fixed now:
https://github.com/rpm-software-management/perl-rpm-packaging/pull/2
There is no strict or warnings (which lead to the undetected error), but I couldn't add it without making further changes and didn't want to break it.
However, there is no testing at all, and Dirk is reluctant to release it now without it being tested.
So I'm thinking of adding some minimal tests.
Updated by tinita about 2 months ago
https://github.com/rpm-software-management/perl-rpm-packaging/pull/3 Add GitHub Action
Updated by tinita about 1 month ago
Working on code coverage: https://github.com/rpm-software-management/perl-rpm-packaging/pull/5
At 100% for perl.prov, now adding a check to ensure that in CI
Updated by tinita about 1 month ago
- Status changed from Workable to In Progress
https://github.com/rpm-software-management/perl-rpm-packaging/pull/5 ready
Working on a basic test for perl.req now
Updated by tinita about 1 month ago
https://github.com/rpm-software-management/perl-rpm-packaging/pull/8 Add unit tests for perl.req
Updated by tinita about 1 month ago
What's left for perl-rpm-packaging:
- Make the scripts usable with perl 5.8 again. We don't know if there are users out there wanting to use the newest rpm on a system with perl 5.8, but the fix is trivial, especially now that the test coverage is good enough.
Updated by tinita about 1 month ago
https://github.com/rpm-software-management/perl-rpm-packaging/pull/9 Make code work on perl v5.18 again
Updated by tinita 22 days ago
- Status changed from In Progress to Workable
Meanwhile perl-rpm-packaging 1.2 was released: https://build.opensuse.org/package/show/openSUSE:Factory/perl-rpm-packaging
I couldn't work on it this week, so I put it back to workable