Kenneth Porter <shiva(a)sewingwitch.com> writes:
This has already been touched on in a couple of other threads, more
as
a matter of figuring out which modules should be removed from core and
made separate packages. A different approach is to use the site
mechanism and library path or some extension of it to allow
replacement modules to coexist with those in core.
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)
Using cpanflute2 one can use "--installdirs=site" to create
a package
that installs to the site directories instead of the vendor
directories. This is almost sufficient to do the job, but there's no
"site" directory for man pages, so one will get install-time conflicts
for those.
<
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142837>
Yeah, the man page thing is a royally frustrating part. The FHS
uncertainty is one of the things that kept me from fixing this before;
it doesn't seem right to throw it over in /usr/local/share/man, but
otherwise you get conflicts. Given /usr/local is meant for site
customization, perhaps it is okay to mix that in with site_perl since
site_perl is meant for site customization. Hmm. Fixing this
ultimately is a bug in perl, as 142837 identified... fix perl and
cpanflute2 will be fixed, too, though it is possible to work around it
with cpanflute2.
But hey, I could change cpanflute2 to at least offer a
--local-manpages option un the meantime, til perl is fixed, that would
move whatever was in /usr/man to /usr/local/man; would that suffice?
Chip
--
Chip Turner cturner(a)pattern.net