(sorry for starting a new thread; just joined the list)
Ahh, the age old conflict of the modules inside of perl vs the modules external to it. Ahh, the pain. Damned if you do, damned if you don't.
... time for a story ... Once upon a time, the happy new Perl maintainer looked around and saw several parts of perl that (he thought) would need updating regularly. "I know what to do!" he said aloud, and quickly split the perl package up into a main perl package and various subpackages such as perl-CGI. "Now when a new perl-CGI comes along, we just release a new RPM made from the CGI upstream distribution, replacing the one that originally was part of perl!"
Woe be unto him, though, that releases an update to a package that comes from a different source rpm. The sky will crack and the earth will boil! Users will be confused, and tools will be flustered. Especially if newer versions of that original package are released, then obsoleting the first update that was from a different source rpm!
And so, only after splitting out the packages did the happy new Perl maintainer realize the error of his ways. Unable to make ammends for past sins, he tucked his tail between his legs, turned the nasty split perl package back into a single package, and went to pay his penance (mucking the stalls for the king). ... the end ...
So my original idea of solving this problem once was to split out perl-CGI and then release updates to it. Bad idea. Wouldn't have worked. So subsequently what I did with things like perl-Time-HiRes was completely destroy them from the perl package so that they -had- to be external packages. You can see examples of such expurgation in the current perl.spec file:
find $RPM_BUILD_ROOT -name '*HiRes*' | xargs rm -rfv find $RPM_BUILD_ROOT -name '*Filter*' | xargs rm -rfv find $RPM_BUILD_ROOT -name '*NDBM*' | xargs rm -rfv
Begone! Begone, foul packages.
So, this is an option for perl-CGI going forward, if frequent updates are anticipated. If not, though, I would recommend just patching it inside of the perl specfile. I am pretty sure I've done that in the past (even with CGI.pm, iirc) with success.
Including the upstream CGI tarball, though, in the RPM as another Source would probably be more trouble than it is worth in terms of getting it to build right and then later updating the spec file to perl 5.8.7 which would no longer need the CGI.pm (in one case you just remove a patch file and a %patch statement; in the other, you excise chunks of the build, etc).
HTH, Chip
Chip Turner,
... So my original idea of solving this problem once was to split out perl-CGI and then release updates to it. Bad idea. Wouldn't have worked. So subsequently what I did with things like perl-Time-HiRes was completely destroy them from the perl package so that they -had- to be external packages. You can see examples of such expurgation in the current perl.spec file:
find $RPM_BUILD_ROOT -name '*HiRes*' | xargs rm -rfv find $RPM_BUILD_ROOT -name '*Filter*' | xargs rm -rfv find $RPM_BUILD_ROOT -name '*NDBM*' | xargs rm -rfv
Begone! Begone, foul packages. ...
A couple of question and notes about the above lines:
1) *HiRes* => perl-Time-HiRes
Do you agree in bringing Time::HiRes back to the perl core package?
Perl 5.8 has been having a pretty fast release cycle with the pumpkin manager Nicholas Clark: a new release almost every four months (although I remember reading somewhere - maybe in the perl5-porters mailing lists - that they were planning in increasing the time between new 5.8 releases to 6 months).
Pumpkin manager Nicholas Clark 5.8.2 2003-Nov-05 5.8.3 2004-Jan-14 5.8.4 2004-Apr-21 5.8.5 2004-Jul-19 5.8.6 2004-Nov-27
2) *Filter* => perl-Filter and perl-Filter-Simple
The removal of Filter files causes similar problems
Filter::Util::Call (perl-Filter) --------------------------------
Perl version Core module Filter::Util::Call 5.008 1.06 5.008001 1.0601 5.008002 1.0601 5.008003 1.0601 5.008004 1.0601 5.008005 1.0601 5.008006 1.0601
CPAN module id = Filter::Util::Call DESCRIPTION Interface for creation of Perl Filters CPAN_USERID PMQS (Paul Marquess pmqs@cpan.org) CPAN_VERSION 1.06 CPAN_FILE P/PM/PMQS/Filter-1.30.tar.gz
The CPAN module version is older than the one shipped with Perl. The CPAN Filter distribution has more files than the ones shipped with perl.
Proposal: Ship the core perl module and drop the external perl-Filter package.
Filter::Simple (perl-Filter-Simple) -----------------------------------
Perl version Core module Filter::Simple 5.008 0.78 5.008001 0.78 5.008002 0.78 5.008003 0.78 5.008004 0.78 5.008005 0.78 5.008006 0.78
CPAN Module id = Filter::Simple DESCRIPTION Simplified source filtering CPAN_USERID DCONWAY (Damian Conway damian@conway.org) CPAN_VERSION 0.79 CPAN_FILE D/DC/DCONWAY/Filter-Simple-0.79.tar.gz
The CPAN module is newer than the one shipped with core Perl.
Try to have it updated upstream (ping perl5-portes).
3) *NDBM* => /dev/null ?
Why has this module been erased? As far as I can tell there is no external perl module being packaged with NDBM.
Regards, jpo
"Jose Pedro Oliveira" jpo@di.uminho.pt writes:
A couple of question and notes about the above lines:
*HiRes* => perl-Time-HiRes
Do you agree in bringing Time::HiRes back to the perl core package?
Perl 5.8 has been having a pretty fast release cycle with the pumpkin manager Nicholas Clark: a new release almost every four months (although I remember reading somewhere - maybe in the perl5-porters mailing lists - that they were planning in increasing the time between new 5.8 releases to 6 months).
Yeah, this makes sense, given the faster turnaround of the 5.8 series lately. Too bad this wasn't the case of 5.8.1, else RHEL3 would have a better perl :(
*Filter* => perl-Filter and perl-Filter-Simple
The removal of Filter files causes similar problems
Ditto here.
*NDBM* => /dev/null ?
Why has this module been erased? As far as I can tell there is no external perl module being packaged with NDBM.
It was removed because it really isn't necessary; there is DB_File which does the same, and on Linux, NDBM is just GDBM anyway, which is part of perl. This reduced the confusion and magic of the NDBM module since ndbm varies from platform to platform, making portable files impossible.
Chip
perl-devel@lists.fedoraproject.org
-
Chip Turner -
Jose Pedro Oliveira