After installing dev-lang/perl-5.12.2-r6 file /usr/lib/perl5/5.12.2/CPAN/Config.pm contain wrong path to ".cpan" directory: "/var/tmp/portage/dev-lang/perl-5.12.2-r6/homedir/.cpan" instead of "/root/.cpan". This path doesn't exists after installing perl, and because of this cpan command fail to work until this path will be manually fixed in that file. Reproducible: Always Portage 2.1.9.25 (hardened/linux/x86, gcc-4.4.5, glibc-2.11.3-r0, 2.6.36-hardened-r9 i686) ================================================================= System uname: Linux-2.6.36-hardened-r9-i686-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-gentoo-1.12.14 Timestamp of tree: Sat, 12 Mar 2011 14:30:01 +0000 app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.6.6-r2, 3.1.3-r1 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 1.12.14-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.5 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.36.1 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/icedtea6-bin-1.9.7/jre/lib/i386/jvm.cfg /service /usr/inferno/keydb /usr/inferno/lib /usr/inferno/services /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /var/log /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=prescott -O2 -pipe" DISTDIR="/usr/portage-distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps=y" FEATURES="assume-digests binpkg-logs distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp.df.lth.se/pub/gentoo/ http://ftp.df.lth.se/pub/gentoo/ http://gentoo.telcom.net.ua/" LANG="ru_RU.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en ru" MAKEOPTS="-j3" PKGDIR="/usr/portage-packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--exclude ChangeLog --delete-excluded" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/powerman /var/lib/layman/sunrise /var/lib/layman/kde-sunset /var/lib/layman/vmware /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d a52 aac acl acpi aim alsa apache2 asf avi bash-completion berkdb bitmap-fonts bzip2 cddb cdr chm cli cracklib crypt cscope cue curl cxx dbus dga divx4linux djvu dlloader dri dts dvd dvdr dvdread encode fastcgi ffmpeg flac flash gd gdbm gif gnutls gpg gtk gtk2 hardened hddtemp iconv icq idn imagemagick imap imlib irc jabber javascript jpeg kde lm_sensors lzo mad mailbox mbox mmx mng modules motif mp3 mpeg msn mudflap musepack mysql ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre perl pic png pppd pwdb python qt qt3support qt4 quicktime readline rss rtc samba sdl session spell sse sse2 ssl ssse3 svg sysfs tcltk tcpd theora tiff truetype truetype-fonts type1-fonts unicode urandom vim-pager vim-syntax vim-with-x vorbis wavpack win32codecs x86 xinetd xorg xv xvid yahoo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="log_config vhost_alias autoindex alias rewrite dir deflate filter mime negotiation auth_basic authn_file authz_host authz_user authz_groupfile cgi actions headers env setenvif" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en ru" LIRC_DEVICES="serial" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="vesa fbdev nv nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
Personally, I don't think you should be running CPAN as root to install things anyway. You're much better off 1. Installing things from portage/perl-experimental overlay 2. Using g-cpan 3. Possibly using 'local::lib' ( dev-perl/local-lib on the experimental overlay ) and/or cpanm ( dev-perl/App-cpanminus on the overlay ) to install things in your users account instead of globally. 4. Optionally, learning to write ebuilds for Perl Modules and possibly contributing them to the overlay.
(In reply to comment #1) > Personally, I don't think you should be running CPAN as root to install things > anyway. You're much better off Is this a joke? Files installed by emerge should NOT contain "/var/tmp/portage/..." substring, in any package. This is a bug, so please just fix it. Adding single `sed` in ebuild should be enough. > 1. Installing things from portage/perl-experimental overlay > 2. Using g-cpan > 3. Possibly using 'local::lib' ( dev-perl/local-lib on the experimental overlay > ) and/or cpanm ( dev-perl/App-cpanminus on the overlay ) to install things in > your users account instead of globally. > 4. Optionally, learning to write ebuilds for Perl Modules and possibly > contributing them to the overlay. I'm using local::lib and cpanm sometimes, but it's not suitable for all tasks. I'm supporting own portage overlay, so I know how to write ebuilds, but thanks for asking. As for perl-experimental and g-cpan, I've no experience with these. We develop a lot of perl applications, which is used in mission-critical production environment, and which is installed using a lot of independent user accounts on same server (mostly to isolate these applications and their developers from other ones). In this situation I prefer to control at least standard CPAN modules used by _all_ these projects by installing and updating them manually and system-wide using cpan command. Additionally we have own internal CPAN mirror with our private modules (which is also installed using standard cpan command). And last but not least - while development (i.e. not on production servers) it's usual to try one or another new CPAN module, which in some cases (like Moose::*) mean installing about 100 CPAN modules as dependencies - and that's just to spend one hour playing with that module. I don't like to spend a lot of time creating ebuilds for missing modules first just to try some module and drop it one hour later. Also it usual to need latest available version of some module. So, I may be wrong, because, as I already said, I've no experience with perl-experimental and g-cpan, but I don't think they provide way to install LATEST version of ANY modules from CPAN and our internal CPAN overlay with all dependencies using just single command like `cpan install Foo::Bar` like we do now. Feel free to correct me if I'm wrong here, I'll be happy to discover better way to install (and uninstall!) perl modules. One more question is about perl-experimental - as I said, we care about our production environment, and I'm not sure using overlay with such a name on production server is good idea. Of course, if this overlay's content is as stable as "x86" portage and only experimental thing there is overlay's name, then I've no reason to bother.
(In reply to comment #2) > > Is this a joke? Files installed by emerge should NOT contain > "/var/tmp/portage/..." substring, in any package. This is a bug, so please just > fix it. Adding single `sed` in ebuild should be enough. I do agree, it was merely a side note, ie: I saw you running into this problem, and I thought about why it it was you were encountering this. =). > As for perl-experimental and g-cpan, I've no experience with these. perl-experimental is a git based overlay with a lot of extra packages we ( perl herd ) maintain. http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=summary It has a fair few modules you can largely just drop in and install. g-cpan ( app-portage/g-cpan ) is a tool for generating and installing ebuilds for various perl distributions automatically. Its not perfect, and I don't use it myself, but many people find it useful. > I'm using local::lib and cpanm sometimes, but it's not suitable for all tasks. > I'm supporting own portage overlay, so I know how to write ebuilds, but thanks > for asking. > We develop a lot of perl applications, which is used in mission-critical > production environment, and which is installed using a lot of independent user > accounts on same server (mostly to isolate these applications and their > developers from other ones). In this situation I prefer to control at least > standard CPAN modules used by _all_ these projects by installing and updating > them manually and system-wide using cpan command. Additionally we have own > internal CPAN mirror with our private modules (which is also installed using > standard cpan command). And last but not least - while development (i.e. not on > production servers) it's usual to try one or another new CPAN module, which in > some cases (like Moose::*) mean installing about 100 CPAN modules as > dependencies - and that's just to spend one hour playing with that module. I > don't like to spend a lot of time creating ebuilds for missing modules first > just to try some module and drop it one hour later. Also it usual to need > latest available version of some module. Yes, for that, CPAN ( or cpanp/cpanm ) and a local::lib configuration seem more optimal for playing around. At least that way its easy to cleanly remove something at a later date and still not need the cognitive overhead of building lots of ebuilds. > So, I may be wrong, because, as I already said, I've no experience with > perl-experimental and g-cpan, but I don't think they provide way to install > LATEST version of ANY modules from CPAN and our internal CPAN overlay with all > dependencies using just single command like `cpan install Foo::Bar` like we do > now. Feel free to correct me if I'm wrong here, I'll be happy to discover > better way to install (and uninstall!) perl modules. My preferred trick for short-lived modules for testing is 'cpanm -l extlibdir Foo::Bar', that way when I'm done playing with it I can just rm -rf extlibdir. Once I'm sure I want to use it long term I'm likely to create an ebuild for it, and often I'll also slot that same ebuild into the aforementioned perl-experimental overlay =). > One more question is about perl-experimental - as I said, we care about our > production environment, and I'm not sure using overlay with such a name on > production server is good idea. Of course, if this overlay's content is as > stable as "x86" portage and only experimental thing there is overlay's name, > then I've no reason to bother. Granted there is a reasonably rapid pace of things there, and things should be considered no more stable than upstream are, but you're not going to be getting "x86" grade stability if you're directly using CPAN anyway. For your production environment setup, you probably want to keep maintaining your own overlay, but you can possibly save yourself a little effort occasionally by cherry-picking commits/ebuilds and soforth from that overlay into your own. I do try to add vendor patches to work around problems upstream haven't released fixes for yet when I encounter them and a reasonable solution is viable, so by at least personally tracking that overlay, you can possibly benefit from out effort =). Also, I should point out that there is another tool *like* g-cpan now, CPANPLUS::Dist::Gentoo ( produced by Vincent Pitt ) http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=tree;f=dev-perl/CPANPLUS-Dist-Gentoo;h=ef975238e947a1f0168cef1bf9238f96da54ca71;hb=HEAD http://search.cpan.org/perldoc?CPANPLUS::Dist::Gentoo which uses CPANPLUS to generate ebuilds, and does a reasonably good job of it. Hope all this helps =).
Also, on further investigation, my dev-lang/perl does not ship CPAN/Config.pm please run 'qfile' to see what created it? =). qfile /usr/lib/perl5/5.12.2/CPAN/Config.pm Thanks.
(In reply to comment #4) > Also, on further investigation, my dev-lang/perl does not ship CPAN/Config.pm Yep, qfile doesn't show it, but on all my systems this file exists after upgrading from perl 5.8.8 to 5.12.2, and it was in /usr/lib/perl/5.12.2/ directory right after emerging perl, so it can't be any sort of junk left by 5.8.8. Only idea I've is my hook: # cat /etc/portage/bashrc.d/dev-lang/perl.postinst #!/bin/bash ewarn "Reinstalling Scalar::Util!" echo force install Scalar::Util | cpan This hook exists because after each reinstalling of perl command $ perl -e 'use Scalar::Util qw( weaken )' broke (I don't remember exact error message, but it is fatal error). Without importing 'weaken', just 'use Scalar::Util' works just fine. Reinstalling Scalar::Util fixes this issue. So, maybe cpan command was executed by user 'portage' while postinst stage, and somehow generate that Config.pm? BTW, thanks for detailed answer about g-cpan and perl-experimental. I've tried to use CPANPLUS for long enough time, but in my experience it proven to be even more buggy than CPAN, so I fallback to cpan. And, to be honest, I don't think generating ebuilds for all CPAN modules is right way to go at all. It sounds like a lot of unreliable and redundant work on top of also not-really-reliable CPAN/CPANPLUS. It's hard to believe in reliability of such tools until I'll see at least one of CPAN/CPANPLUS/CPANMINUS working reliably. I will not talk about CPANMINUS because I didn't used it extensively yet, but in CPAN/CPANPLUS I've seen same issues for years: they fail to correctly detect latests version number for some modules, fail to correctly detect and install all dependencies, even fail to correctly install some modules in batch mode (because these modules ask user to answer questions while make Makefile.PL, but it always enough to just press Enter for default answers and CPAN fail to do this for some modules), fail to correctly support local CPAN overlays…
(In reply to comment #5) > (In reply to comment #4) > > Also, on further investigation, my dev-lang/perl does not ship CPAN/Config.pm > > Yep, qfile doesn't show it, but on all my systems this file exists after > upgrading from perl 5.8.8 to 5.12.2, and it was in /usr/lib/perl/5.12.2/ > directory right after emerging perl, so it can't be any sort of junk left by > 5.8.8. > > Only idea I've is my hook: > # cat /etc/portage/bashrc.d/dev-lang/perl.postinst > #!/bin/bash > ewarn "Reinstalling Scalar::Util!" > echo force install Scalar::Util | cpan > > This hook exists because after each reinstalling of perl command > $ perl -e 'use Scalar::Util qw( weaken )' > broke (I don't remember exact error message, but it is fatal error). > Without importing 'weaken', just 'use Scalar::Util' works just fine. > Reinstalling Scalar::Util fixes this issue. > > So, maybe cpan command was executed by user 'portage' while postinst stage, and > somehow generate that Config.pm? > That does seem to be a likely explanation for what has happened. If 'qfile' is not showing it, then no package owns it, so that generally points out "its something you did". ( not always the case, but often is ) The only way to know for sure is removing that hook on a yet-to-be-upgraded box and then upgrade it and see if your problem repeats. Further more, that hack you have with scalar::util, if it is still posing a problem for you, should be reported =).
Yes, i agree. The system-wide CPAN/Config.pm is created by your hook. Nothing we can fix. Please file a new bug for the Scalar::Util problem if it still exists. Thanks
(In reply to comment #7) > Please file a new bug for the Scalar::Util problem if it still exists. I've just tested it, and looks like this problem doesn't exists. Probably it was actual only for 5.8.8, so I'll remove that hook. Thanks.
