(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 cturner(a)pattern.net
