(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@xxxxxxxxxxx
