Description of problem: The perl rpm Obsoletes a number of modules which are now included in base perl 5.8.8. However some of these modules do get updated fairly regularly in between perl releases. As a system builder I prefer to update them by building an RPM with cpanflute for the specific module e.g. perl-Time-HiRes, so that I get simple and repeatable installations. But because of the Obsoletes in the perl RPM I have to remember which are in base perl and choose non-standard module names to get round it. If the Obsoletes tag could be made versioned, against the actual module version included in perl, it would simplify the task of keeping systems up to date between Fedora releases. It would also make it it much easier when Fedora perl is updated because $PACKAGE_MANAGER could be trusted not to remove newer modules. At the time of writing the tags for perl 5.8.8 would be: Obsoletes: perl-Digest-MD5 <= 2.36 Obsoletes: perl-MIME-Base64 <= 3.07 Obsoletes: perl-libnet <= 1.19 Obsoletes: perl-Storable <= 2.15 Obsoletes: perl-CGI <= 3.15 Obsoletes: perl-CPAN <= 1.7602 Obsoletes: perl-DB_File <= 1.814 Obsoletes: perl-Filter <= 1.32 Obsoletes: perl-Filter-Simple <= 0.82 Obsoletes: perl-Time-HiRes <= 1.86 Obsoletes: perl-Test-Builder-Tester <= 1.02 Version-Release number of selected component (if applicable): 5.8.8-8
This seems like a reasonable suggestion. Do we have some plan to do this for F9 / 5.10? Or is there some other plan to deal with modules included in the perl package?
Some of the mentioned packages already are obsoleted in F-8 perl. I can add other to F-8 spec file. What for F-9 perl-5.10? Any thoughts?
I'm not sure about this. If we add these Obsoletes, we'd want to also add the versioned Provides. The base perl package already provides versioned provides for everything inside of it (in perl(Foo::Bar) format), so we'd be adding a rather large set of duplicate Provides to the spec file. The only Obsolete entry in the rawhide perl spec is: Obsoletes: perl-File-Temp < 0.18 There are no other hardcoded Obsoletes, so you should not be hitting the problem you're describing. :)
I see, so we can close it.