Overriding core Perl modules

[Chip Turner]

Kenneth Porter <shiva at sewingwitch.com> writes:

> --On Wednesday, April 27, 2005 11:43 AM -0400 Chip Turner
> <cturner at pattern.net> wrote:
>
>> Yep, this option works too, except that upgrading to a new Perl would
>> still use the old module.  Probably okay.  (or is rawhide set so that
>> site_perl comes before vendor_perl and even the local perl's dirs,
>> now?  I think I fixed that, not sure)
>
> That would be nice. Currently (FC2 for me) one must issue a "use lib"
> in code that needs to override builtins with site libs.

Sadly it only gets us part of the way there.  Other files, besides
manpages pop up.  /usr/bin is a common one, but easily dealt with.
The real scary one is /usr/share/doc -- the files aren't in the
buildroot when %install is being run!  RPM places them there later.
This is difficult to avoid short of ignoring the local policy and
redefining docdir or somesuch... which I am not totally in favor of.
The net result there is although you could still perhaps override core
perl modules with these kinds of RPMs, you can't really install two
concurrent ones (ie, perl-Foo-1.1 and perl-Foo-1.2) since they would
conflict over docdir.

RPM-Specfile-1.19 is being uploaded to CPAN tonight.  It contains this
change (--use-usr-local, horrible name, alas) as well as the code to
detect the name of the top level tarball.

Please give it a whirl!

Thanks,
Chip

-- 
Chip Turner                   cturner at pattern.net