Bug 486579

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 ;-)

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.

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.

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.

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

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.

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.

[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?

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.

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.