Bug 486579 - Suggest splitting perl-CGI into its own package
Suggest splitting perl-CGI into its own package
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Stepan Kasal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-20 07:58 EST by Ed Avis
Modified: 2009-04-28 03:37 EDT (History)
5 users (show)

See Also:
Fixed In Version: 5.10.0-68.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-04 16:06:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ed Avis 2009-02-20 07:58:12 EST
The Perl module CGI.pm is a dual-lifed module.  That is, a version of it ships as part of the core perl distribution, but it is also available on CPAN.  The CPAN version may be more recent than that included with the current perl release.

To make it possible to upgrade CGI.pm without patching and rebuilding the whole perl5 distribution, I suggest splitting out CGI.pm into its own package perl-CGI, with the code taken from CPAN.  (The perl package would then have Requires: perl-CGI to reflect the fact that this is a module that should always be present.)
Comment 1 Marcela Mašláňová 2009-02-20 08:40:35 EST
Thanks for suggestion but in this case we can split many other modules. From time to time we are doing update of core modules anyway, usually when someone need it. Anyway perl is updated every month for some bug fix. 

I believe you are asking for updated version of CGI to 3.42 ;-)
Comment 2 Tom "spot" Callaway 2009-03-04 16:06:07 EST
Closing this one out, as we're not going split off the dual-lifed modules (it would make perl rather painful to bootstrap). If you need an newer CGI.pm, feel free to reopen with details.
Comment 3 Stepan Kasal 2009-03-05 04:05:55 EST
The request as such was rejected, it's not feasible to split out all the modules packed with perl tarball; details are nicely explained in comment #2.

But let me add that I understand your needs:
1) It's unfortunate that these modules cannot be overrided by modules installed to sitedir.  We are going to consider reordering @INC so that sitelib would come before privlib; this change might happen when perl-5.10.1 comes out.
2) I'm working on an update of perl.rpm that would contain an updated version of CGI-3.42, it should appear in Fedora 10 testing updates in the course of days.
Comment 4 Stepan Kasal 2009-03-23 13:20:12 EDT
Hello,
the following promises materialized now:

(In reply to comment #3)
> 1) It's unfortunate that these modules cannot be overrided by modules installed
> to sitedir.  We are going to consider reordering @INC so that sitelib would
> come before privlib; this change might happen when perl-5.10.1 comes out.
> 2) I'm working on an update of perl.rpm that would contain an updated version
> of CGI-3.42, it should appear in Fedora 10 testing updates in the course of
> days.  

Both have happened in perl-5.10.0-62:
1) sitelib overrides the Fedora-provided modules,
2) you don't need it right now, because the distributed CGI.pm was updated to 3.42

Enjoy.

Changing the resolution to "fixed in rawhide"; even though the suggestion in the title was declined, the problem has been addressed.
Comment 5 Fedora Update System 2009-03-23 13:22:34 EDT
perl-5.10.0-63.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/perl-5.10.0-63.fc10
Comment 6 Fedora Update System 2009-04-21 20:54:34 EDT
perl-5.10.0-68.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 7 Fedora Update System 2009-04-21 21:08:16 EDT
perl-5.10.0-68.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 8 Ed Avis 2009-04-26 18:10:48 EDT
[discussion follows]

>1) sitelib overrides the Fedora-provided modules,
>
>2) you don't need it right now, because the distributed CGI.pm was updated
>to 3.42

In a way (1) obsoletes (2), is that so?

If sitelib comes earlier in the PERL5LIB search path, then the simplest way to push out an update of CGI (or any other dual-life module) is to leave the base perl package untouched, and release a new perl-CGI rpm.  There would be two copies of the file CGI.pm installed on the system, but that mess accurately reflects the upstream situation...

Is that going to be the Fedora way to update these modules from now on, or are you going to continue patching them into the base perl rpm?
Comment 9 Stepan Kasal 2009-04-27 06:39:12 EDT
Hello,

(In reply to comment #8)
> >1) sitelib overrides the Fedora-provided modules,
> >
> >2) you don't need it right now, because the distributed CGI.pm was updated
> >to 3.42
> 
> In a way (1) obsoletes (2), is that so?

not at all, sitelib can be populated only by the administrator of the individual machines, no rpm can install anything to sitelib.  (That also corresponds with the fact that sitelib is under /usr/local.)

> If sitelib comes earlier in the PERL5LIB search path, [...]

Terminology nitpicking: we are discussiong perl's @INC list here.  That list is built at the startup of perl (PERL5LIB is an environment variable that enables you to insters some paths to the beginning of the @INC list and is not much relevant here.)

> [...] then the simplest way to
> push out an update of CGI (or any other dual-life module) is to leave the base
> perl package untouched, and release a new perl-CGI rpm.  There would be two
> copies of the file CGI.pm installed on the system, but that mess accurately
> reflects the upstream situation...
> 
> Is that going to be the Fedora way to update these modules from now on, or are
> you going to continue patching them into the base perl rpm?  

It is definitely not the Fedora way to distribute two copies of CGI.pm, that would be confusing.

I do not see any significant problem with the current setup where the dual core modules get updated in the base perl rpm.  The advantage is that perl slowly evolves towards the next release, so that the update to 5.10.1 is not going to be a dangerous jump.
Comment 10 Ed Avis 2009-04-28 03:37:21 EDT
Ah, the siteperl directory is just for administrators who want to 'manually' install new modules without using rpm.  I misunderstood.

>I do not see any significant problem with the current setup where the dual core
>modules get updated in the base perl rpm.

The current setup may be the best compromise, but it does have problems.  If you want to push out a newer version of CGI.pm or any other dual-life module you have to manually patch it into the 'perl' package and rebuild the whole thing.  In fact you need to build a different perl package for every combination of module versions - they cannot be upgraded or downgraded independently.  For example, I needed to apply a patch to the File::Temp module.  Rather than just making a new perl-File-Temp package and pushing that out, it was necessary to rebuild the whole of perl and its associated packages.  Most likely the changes will be overwritten when a new Fedora package of perl comes out and will need re-applying.  (I could mark my custom package with a higher epoch to stop it being replaced, but then would not get any updates and security fixes.)  By contrast having one rpm per Perl module makes administration much easier.

Note You need to log in before you can comment on or make changes to this bug.