Proposal: move site to /usr/local
This seems to be in line with the Perl 5 installation guideline, which specifies (as an example): $prefix /usr $siteprefix /usr/local $vendorprefix /usr I wonder how an upgrade path would look like, though... I guess the @INC path would still have to include the old /usr/lib/perl5/site_perl too.
(In reply to comment #1) > I wonder how an upgrade path would look like, though... Upgrade path is no problem: If we change this for perl-5.14 (~April 2011), users have to rebuilt all their modules anyway (at least with current perl-cleaner). > I guess the @INC path would still have to include the old > /usr/lib/perl5/site_perl too. Do you have any modules installed in /usr/lib/perl5/site_perl (not in ../$perl_version/ !) ?
Shouldn't /usr/local have a big "KEEP OFF THE GRASS" sign as far as the package manager is concerned? Shouldn't stuff installed by the package manager go in "vendor_perl" anyway?
(In reply to comment #3) > Shouldn't stuff installed by the package manager go in "vendor_perl" anyway? Answering my own question: "Yes they should and that's what this bug's dependency tree is for!"
As this is about the only REAL blocker for 5.14, is it possible we could get some push for a fix? Seems like we are within spitting distance of getting 5.14 sorted - can we please push to complete? Thanks
It is a pity we do not have Perl 5.14 just because of this academic question... Is it possible to close this issue and continue discussing *while* having Perl 5.14?
I vote against this change. The system perl should be in /usr. Users put their own stuff, not managed by the system (emerge) in /usr/local (or, really, wherever they want). http://www.pathname.com/fhs/2.2/fhs-4.9.html points out that the "/usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated." In other words, if a system administrator has installed perl to /usr/local themselves (easy enough to do), updating the system software (dev-lang/perl) *must not* overwrite it. Therefore I propose this bug as invalid. (The vendor vs site question is separate and is, IMO, valid.)
Agreed. This bug should be invalid. Perl Modules installed to /usr/local should be only installed there under a perl also installed in /usr/local. Perl Modules applying from /usr/local to shadow /usr/share/ is in that context, just wrong. If a user is certain they want to install things to /usr/local, then they can do so by changing PERL5LIB globally, or by augmenting $Config{sitelib}/sitecustomize.pl Though even that I would recommend against. Because a user mixing CPAN.pm and Portage, regardless of how you do it, is going to end in misery. dev-lang/perl should be primarily for Gentoo dependencies, and other things installed by portage. If you wish to extend it, use local::lib and install to ~/ or a directory of your choosing, so as not to break the Portage controlled versions of Perl Modules. Though if you're doing anything advanced, Perlbrew is recommended.
I don't see why the perl 5.18 tracker defect is pointing to this at all. This bug should be invalid. Even the base assumptions are incorrect. Perl does not specify /usr/local for siteprefix. It is using that as an odd example and how perl's Configure script will handle it. From https://metacpan.org/pod/distribution/perl/INSTALL#Directories-for-vendor-supplied-add-on-files it says "For example, a vendor might choose the following settings:" right before the bit mephinet quotes in comment #1. Please stop using this defect, please just close it as invalid, reverting any /usr/local setup, and then move on. Because this is really invalid. VENDORS SHOULD NOT BE PUTTING ANYTHING IN /usr/local. Thank you.
Fine with me, using vendor is probably the right thing to do!
Perl modules installed by portage should NOT go into /usr/local, as portage should NOT put anything there. +1 for closing this as INVALID/WONTFIX
(In reply to Sergey Popov from comment #11) > Perl modules installed by portage should NOT go into /usr/local, as portage > should NOT put anything there. +1 for closing this as INVALID/WONTFIX Have read all comments, and i agree, no make sense to do it. Closed.
