Currently, g-cpan is broken: grunt ~ # g-cpan -i Linux::Inotify CPAN: Storable loaded ok Going to read /root/.cpan/Metadata Database was generated on Mon, 23 Oct 2006 01:23:03 GMT * g-cpan: Looking for Linux::Inotify CPAN: Digest::SHA loaded ok CPAN: Compress::Zlib loaded ok Checksum for /root/.cpan/sources/authors/id/T/TW/TWERNER/inotify/Linux-Inotify-0.04.tar.gz ok Scanning cache /root/.cpan/build for sizes Linux-Inotify-0.04/ Linux-Inotify-0.04/lib/ Linux-Inotify-0.04/lib/Linux/ Linux-Inotify-0.04/lib/Linux/Inotify.pm Linux-Inotify-0.04/lib/Linux/Inotify/ Linux-Inotify-0.04/lib/Linux/Inotify/Watch.pm Linux-Inotify-0.04/lib/Linux/Inotify/Event.pm Linux-Inotify-0.04/META.yml Linux-Inotify-0.04/eg/ Linux-Inotify-0.04/eg/inotify.pl Linux-Inotify-0.04/MANIFEST Linux-Inotify-0.04/ChangeLog Linux-Inotify-0.04/MANIFEST.SKIP Linux-Inotify-0.04/INSTALL Linux-Inotify-0.04/t/ Linux-Inotify-0.04/t/inotify.t Linux-Inotify-0.04/README Linux-Inotify-0.04/Makefile.PL Linux-Inotify-0.04/Build.PL Linux-Inotify-0.04/LICENSE Removing previously used /root/.cpan/build/Linux-Inotify-0.04 CPAN: Module::Build loaded ok Strange distribution name [perl] Strange distribution name [perl] * g-cpan: perl is not a CPAN module! * g-cpan: Ebuild already exists for perl Exiting subroutine via next at /usr/bin/g-cpan line 486. Exiting subroutine via next at /usr/bin/g-cpan line 486. * g-cpan: Generating ebuild for Linux::Inotify * g-cpan: Ebuild generated for Linux-Inotify * g-cpan: Nothing to install!! Alright, so I checked: grunt ~ # ls /usr/local/portage/perl-gcpan/Linux-Inotify/ Linux-Inotify-0.04.ebuild Manifest files grunt ~ # emerge Linux-Inotify Calculating dependencies emerge: there are no ebuilds to satisfy "Linux-Inotify". grunt ~ # emerge -p perl-gcpan/Linux-Inotify These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] perl-gcpan/Linux-Inotify-0.04 I would guess that g-cpan is using the short name. But why doesn't the short name (Linux-Inotify) work with the CPAN overlay? Other, custom overlay stuff works just fine: grunt ~ # ls /usr/local/portage/dev-ruby/rubyzip/ Manifest files rubyzip-0.5.12.ebuild grunt ~ # emerge -p rubyzip These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-ruby/rubyzip-0.5.12 So why doesn't CPAN work properly? This seems to be a bug in both g-cpan and Portage. My overlay looks to be set up properly: grunt ~ # emerge --info Portage 2.1.1-r1 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.4-r3, 2.6.17.13 x86_64) ================================================================= System uname: 2.6.17.13 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.12.5 Last Sync: Mon, 23 Oct 2006 20:00:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=athlon64 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=athlon64 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://mirror.tds.net/gentoo ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X a52 aac aalib acpi adns alsa apache2 audiofile avi bash-completion berkdb bitmap-fonts bzip2 cdparanoia cdr cli cracklib crypt cups dbus dedicated divx4linux dlloader doc dri dvb dvd dvdr dvdread elibc_glibc emul-linux-x86 encode ffmpeg firefox flac ftp gcj gdbm gif gpm grammar gstreamer imap input_devices_keyboard input_devices_mouse ipv6 isdnlog ithreads jpeg kernel_linux ladcca libg++ libgda lirc lm_sensors mad maildir math matroska mikmod mmap mp3 mpeg mysql nas ncurses nls nocd nptl nptlonly ocaml offensive ogg oggvorbis opengl pam pcre pdf perl png ppds pppd python quicktime readline reflection samba session shorten slang socks5 speex spell spl ssl szip t1lib tcpd theora thesaurus threads tiff truetype-fonts type1-fonts udev unicode usb userland_GNU v4l vcd vhosts video_cards_ati video_cards_vga videos vorbis wmf wordperfect xml xml2 xorg xpm xv xvid zip zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Has nothing to do with portage; also kindly read https://bugs.gentoo.org/page.cgi?id=fields.html#bug_severity
Apologies about the bug severity, although it is blocking me from doing development work (though not necessarily Gentoo-related dev work). Adjusting to "major", because having g-cpan not actually install the package means I may as well not have g-cpan at all. It seems more likely that it's a Portage bug than a g-cpan one, though. Kindly read the report: g-cpan is doing exactly what I would do (emerge Foo-Bar), but it only works when given the category (emerge perl-gcpan/Foo-Bar). How is this not a Portage bug? And if it is not a Portage bug, what is normally required to make a short name work? That is, what is so special about every other package in portage, like -- oh, I don't know, my custom cdemu ebuild -- that allows the shortname to work? I've created an ebuild in app-cdr/cdemu, in the same overlay -- mostly a version bump. I'll probably submit it soon. I can install it with "emerge cdemu" -- I'm not required to type "emerge app-cdr/cdemu". I admit this could be a bug in how g-cpan creates ebuilds, but again: What could g-cpan possibly be doing wrong that would cause this behavior? Why have I never run into this when manually creating ebuilds?
I'm seeing this exact same problem; perhaps it's because perl-gcpan isn't in /usr/portage/profiles/categories? If that's the case, it's either a) a portage bug because that category should be present in the categories file, or b) a g-cpan bug, because it should emerge using the catname/pkgname syntax because its custom category isn't registered. Regardless, it's a bug.
(In reply to comment #3) > I'm seeing this exact same problem; perhaps it's because perl-gcpan isn't in > /usr/portage/profiles/categories? check /etc/portage/categories - current versions of g-cpan make sure there's an entry in there now
>>> Merging perl-gcpan/Linux-Inotify-0.04 to / Which version of g-cpan was this tested under?
(In reply to comment #4) > (In reply to comment #3) > > I'm seeing this exact same problem; perhaps it's because perl-gcpan isn't in > > /usr/portage/profiles/categories? > > check /etc/portage/categories - current versions of g-cpan make sure there's an > entry in there now I suppose I can add this manually. I'm running g-cpan 0.14.0, and I just synced today. If there's some "current version" that fixes this, it needs to be taken out of ~arch/mask/whatever, because this version does not work.
If you're running as root, it writes the file in /etc/portage. If you're not, and it can't, it doesn't. This has been a "feature" of 0.14.0 the whole time.
(In reply to comment #7) > If you're running as root, it writes the file in /etc/portage. If you're not, > and it can't, it doesn't. I am running as root, and it doesn't write to the file. Adding it manually works, such as it is, although I'm still running into bug #156230.
FWIW, the version in svn installs Linux::Inotify perfectly...
Line 194 was the culprit. Corrected in svn (http://sources.gentoo.org/viewcvs.py/gentoo-perl/g-cpan/trunk/), should be in rc1 shortly.
