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.
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
My own involvement is in installing MIMEDefang (http://mimedefang.org/), which requires a raft of Perl modules, some of which are updates to those in core. Most were easy enough to repackage with cpanflute2, but a couple required a bit of intervention to deal with unusual tarball names and conflicts with Perl core packaging.
Kenneth Porter shiva@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.
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
--On Wednesday, April 27, 2005 11:43 AM -0400 Chip Turner cturner@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.
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?
That would be a good interim workaround until Perl and FHS figure out the Right Thing.
Kenneth Porter shiva@sewingwitch.com writes:
--On Wednesday, April 27, 2005 11:43 AM -0400 Chip Turner cturner@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
--On Monday, May 02, 2005 4:48 AM -0400 Chip Turner cturner@pattern.net wrote:
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.
Are you talking about /usr/share/doc/*? On my FC2 installation, the subdirectory names in that directory have both package name and version, so multiple docdirs can coexist. That hasn't changed since FC2, has it?
Kenneth Porter shiva@sewingwitch.com writes:
--On Monday, May 02, 2005 4:48 AM -0400 Chip Turner cturner@pattern.net wrote:
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.
Are you talking about /usr/share/doc/*? On my FC2 installation, the subdirectory names in that directory have both package name and version, so multiple docdirs can coexist. That hasn't changed since FC2, has it?
Ah, of course, good point. I must be blind :)
Chip
--On Monday, May 02, 2005 4:48 AM -0400 Chip Turner cturner@pattern.net wrote:
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.
Just got to try this to update MIME-Base64 to 3.05 on FC2. The magic command looks like this:
cpanflute2 --buildall --use-usr-local --installdirs=site MIME-Base64-3.05.tar.gz
I installed the result and then built MIME-tools-5.417 and didn't get its warning about an old MIME-Base64, so it seems to work so far.
Kenneth Porter shiva@sewingwitch.com writes:
--On Monday, May 02, 2005 4:48 AM -0400 Chip Turner cturner@pattern.net wrote:
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.
Just got to try this to update MIME-Base64 to 3.05 on FC2. The magic command looks like this:
cpanflute2 --buildall --use-usr-local --installdirs=site MIME-Base64-3.05.tar.gz
I installed the result and then built MIME-tools-5.417 and didn't get its warning about an old MIME-Base64, so it seems to work so far.
Awesome!
Chip
On Wed, 2005-04-27 at 11:43 -0400, Chip Turner wrote:
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.
I think prefixing the whole site_perl hierarchy to /usr/local would be good. Implementing that could get somewhat messy though: it shouldn't be just declared that site_perl below /usr/lib/perl5 is no longer in @INC, but compat symlinks would have to be provided. But the site_perl dirs below /usr/lib/perl5 cannot be overwritten with symlinks on upgrades...
In the FHS sense, I don't think the site_perl relocation would be a problem per se. It could be seen as a problem in non-locally packaged Perl modules that install therein though, but that's not a showstopper for the relocation plan IMO.
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?
Hm, is there a "/share" missing before "/man" in both paths above?
--On Wednesday, April 27, 2005 7:43 PM +0300 VilleSkyttä ville.skytta@iki.fi wrote:
I think prefixing the whole site_perl hierarchy to /usr/local would be good.
Are you equating site_perl to /usr/local, then? I think of the latter as a place to put unpackaged stuff, so I'd still want a place to put packaged Perl modules that don't come with core or that override it with newer components.
On Wed, 2005-04-27 at 10:24 -0700, Kenneth Porter wrote:
--On Wednesday, April 27, 2005 7:43 PM +0300 VilleSkyttä ville.skytta@iki.fi wrote:
I think prefixing the whole site_perl hierarchy to /usr/local would be good.
Are you equating site_perl to /usr/local, then?
Not equating, but prefixing. But we probably talk about the same thing, ie. /usr/local/lib/perl5/site_perl, /usr/local/share/man, /usr/local/bin.
I think of the latter as a place to put unpackaged stuff, so I'd still want a place to put packaged Perl modules that don't come with core or that override it with newer components.
I don't think there is anything wrong with installing *local* stuff into /usr/local (packaged or not), that's what the /usr/local hierarchy exists for anyway. That would help with the "override core" part. For stuff that isn't shipping in the repositories one uses, there would be the choice of using vendor (or site) install dirs.
Ville Skyttä ville.skytta@iki.fi writes:
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?
Hm, is there a "/share" missing before "/man" in both paths above?
Yeah, my bad. What it does now (when --use-usr-local is specified) is this:
for dir in bin share/doc share/man; do if [ -d $RPM_BUILD_ROOT/usr/$dir ]; then mkdir -p $RPM_BUILD_ROOT/usr/local/$dir mv $RPM_BUILD_ROOT/usr/$dir/* $RPM_BUILD_ROOT/usr/local/$dir/ rm -Rf $RPM_BUILD_ROOT/usr/$dir fi done
So /usr/bin, /usr/share/doc, and /usr/share/man are all migrated over to /usr/local (though share/doc shouldn't be there... you never know)
Chip
perl-devel@lists.fedoraproject.org
-
Chip Turner -
Kenneth Porter -
Ville Skyttä