After upgrading to sys-devel/perl version 5.6.1-r5, I noticed that all ebuilds that install Perl modules were placing the modules into the wrong directory, i.e. /usr/lib/site_perl/... instead of /usr/lib/perl5/site_perl/... The problem is caused by a bug in the module ExtUtils::MakeMaker. Upgrading to the latest version of this module fixes the problem.
Was this in the last two days? There was an error in the perl-modules.ebuild class that was fixed last night that did the exact same thing (installed to /usr/lib instead of /usr/lib/perl5)
Yes it was. Is the ebuild fix a workaround for the bug in MakeMaker?
I took a look at the new perl-modules.ebuild. I don't see anything in there that would fix the problem. You can actually see the bug just by running "perl Makefile.PL PREFIX=/something/other/than/usr on some Perl module, i.e. run perl Makefile.PL PREFIX=/tmp/foo/usr and it will create a Makefile with various install locations that point to: /tmp/foo/usr/site_perl instead of: /tmp/foo/usr/perl5/site_perl This basically breaks the install of all Perl module ebuilds, as the incorrect directories are not on the Perl module path (INC). As I mentioned before, upgrading the MakeMaker module fixes this. IMO, the fixed version of the module should be included in the perl ebuild rather than attempting to hack around the old one, but of course that's your call.
The new eclass file was actually to address sandboxing issue for perl 5.8 users (worth a shot for your problem though - symptoms were the same when the bad fix for the eclass was up). While looking into your problem, I came across the following at perl.org. No specified resolution though. http://bugs6.perl.org/rt2/Ticket/Display.html?id=7011 I am still looking into this. Unfortunately, forcing an emerge following an ebuild isn't the same as a DEPEND, and unless the user uses --config to emerge perl (and we include the perl -MCPAN config one liner) there's no way to use cpan after the ebuild.
FYI, bug 6450 is mine and inquires about adding a PDEPEND (or some such) to portage to be able to address unique issue like this. Thanks, Mike
I've the same problem. I'm having two machines, both with portage 2.0.13 and perl 5.6.1-r4. On one machine emerging perl-modules runs fine (I've just written 7 new ebuilds for modules I needed) on the other all is installed at /usr/lib/5.6.1 and /usr/lib/site_perl as described here. So it must be a problem besides portage or perl. Any hints?
I found a comment on the Perl newsgroups that the problem was caused by the version of MakeMaker. Upgrading this module (outside of an ebuild, i.e. via CPAN) fixed the problem for me.
If anyone wants me to test some things, please response fast. I let the machine broken until Sunday, but then I will try to fix it.
This problem will be closed in the next few days :) Commited to portage and tested is an ebuild for MakeMaker 6.0.3. In a few days, once the ebuild has filtered out everywhere safely, I will be committing a new version of the perl- module.eclass that requires this ebuild if you are running perl 5.6.1 (it comes with 5.8). The ebuild and eclass have been tested on x86, sparc, sparc64, and ppc successfully.
I tried installing the module you mentioned (emerge ExtUtils-MakeMaker). I get the following error: >>> Install ExtUtils-MakeMaker-6.03 into /var/tmp/portage/ExtUtils-MakeMaker- 6.03/image/ category dev-perl ACCESS DENIED open_wr: /usr/lib/perl5/5.6.1/ExtUtils/Liblist.pm Installing /usr/lib/perl5/5.6.1/ExtUtils/Liblist.pm ACCESS DENIED utime: /usr/lib/perl5/5.6.1/ExtUtils/Liblist.pm ACCESS DENIED chmod: /usr/lib/perl5/5.6.1/ExtUtils/Liblist.pm ACCESS DENIED chmod: /usr/lib/perl5/5.6.1/ExtUtils/MM_Cygwin.pm ACCESS DENIED unlink: /usr/lib/perl5/5.6.1/ExtUtils/MM_Cygwin.pm Cannot forceunlink /usr/lib/perl5/5.6.1/ExtUtils/MM_Cygwin.pm: Permission denied at /usr/lib/perl5/5.6.1/File/Find.pm line 519 make: *** [pure_perl_install] Error 255 !!! ERROR: The ebuild did not complete successfully. !!! Function perl-module_src_install, Line 17, Exitcode 2 !!! (no error message) !!! emerge aborting on /usr/portage/dev-perl/ExtUtils-MakeMaker/ExtUtils- MakeMaker-6.03.ebuild .
To try the module, you will need to backup your current perl-modules.eclass in /usr/portage/eclass (or wherever your portage tree is) and replace it with the perl-modules-test.eclass file. The syntax will be changing in the eclass module and should work with extutils. I unmasked extutils so that i knew it was safely out there and available (not listed as masked on your machines) before committing the new eclass officially. Please give the above a try and let me know if it doesn't work. So far, I've had successful tests on three i686's, a ppc, a sparc, and a sparc64 - but that doesn't mean I've missed something. Thanks! Mike
What I doesn't understand is where are the difference between my two machines. Both are using the same perl and portage. (I'm no perl guru, so I haven't any clue where to search ;) )
FYI, I've held off on release the new eclass until I make sure all ebuilds work with it. I've found a few ebuilds that do not like the new makemaker's syntax and am working through the tree fixing them. Just so you didn't wonder what happened.
157 of 160 perl-modules install correctly with the new makemaker (includes about 7 fixed ebuilds). Testing the external, non-module (but still uses perl's makemaker) ebuilds now.
Testing for the new eclass is done, all modules and packages have been updated, and this has been commited. Thanks for your patience, Michael
The new MakeMaker is out there now and in use. See all other bugs assigned to me if in doubt :)
