Kenneth Porter <shiva@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxx
