I'd been away from Perl for a little while ... long enough, you know, to forget a few things (like, say, "everything"). Long enough, in particular, to be momentarily baffled by an error in the "uncompress" routine when I tried to use CPAN after a long absence.

"It's all coming back to me now," but for You, Gentle Reader, let me summarize what I did to solve the problem.

First of all, since I do a lot of maintenance of Perl-based web-sites (on a Gentoo Linux system, whose core system-maintenance system is also Perl-based), I maintain my own separate versions of most Perl packages. (It's just like what you have to do when you're working on a virtual-host environment, and you of-course can't update the Perl environment of the host system, but must arrange things particularly for "this or that site.") This means that, in my CPAN configuration, I've got my own custom settings for make_install_arg and makepl_arg, to define "SITEPREFIX=" and "PREFIX=",respectively.

CPAN wasn't working because it would no longer uncompress things. So, in a nutshell, this is what I did.

First, I went to CPAN and downloaded IO::Compress::ZLib. I uncompressed the tar file and moved the resulting folder to my local ~/.cpan/build directory, then cd'd to it. I then reviewed the README for further instructions. When I performed the perl Makefile.PL step, it told me that I had an outdated prerequisite module.

Therefore, I downloaded the prereq, Compress::Raw::ZLib, and prepared it using the sequence I will now describe. (So, I did this and then I then went back and did the same for IO::Compress::ZLib, but I won't repeat myself.)

Executing the cpan command and then using o conf, I wrote down the settings for makepl_arg (let's say it was PREFIX="/mysites"), and make_install_arg (say it was SITEPREFIX="/mysites"). Then I quit cpan.

I cd'd into ~/.cpan/build/IO-Compress-Zlib-2.015 (this being the version I'd just downloaded) and entered the command: perl Makefile.PL PREFIX="/mysites"

Next two steps (according to the README) were make then make test

I now attempted to do SITEPREFIX="/mysites" make install but it failed because it was trying to uninstall the host's version ... which my non-rootly userID (quite by-design) could not do.

This was remedied by specifying that I didn't want to uninstall: SITEPREFIX="/mysites" UNINST=0 make install This time, it installed properly.

Now, having thusly installed the pre-requisite, I went back and installed IO::Compress::ZLib using the same procedure. (I told you I wouldn't repeat myself...)

Once this was done, CPAN was up-and-running again. I started bringing my installation back up-to-date by upgrading and reloading CPAN, then the other packages that were by now gathering so much dust.

I hope this helps somebody.

Replies are listed 'Best First'.
Re: How I fixed it: CPAN crashing on "Uncompress"
by Tanktalus (Canon) on Dec 10, 2008 at 05:27 UTC

    First off, Gentoo's system is largely written in Python, not Perl. :-P There are aspects of it in shell, as well, but the base is Python. You may have a few odd tools written in Perl, or C/C++ (like eix), but it's still basically Python/shell.

    Second, since the system is written in python, shell, and C (awk, sed, grep, unzip, gcc, etc.), you probably could have just re-emerged perl and any other modules that you needed. Probably easier than what you did :-) If you're maintaining your own parallel setup, it might be worth it to simply copy the existing perl ebuilds to new groups (e.g., dev-perl/myperl and dev-myperl/ and myperl-core), copy over the ebuilds with some minor, automatable difference, and then let portage handle the rest.

    Finally, a couple Gentoo/perl must-haves: if you haven't found it yet (it took me years of using Gentoo before someone mentioned this to me), check app-portage/g-cpan. It's entirely worth the effort to set up. Really. It bridges the gap between cpan and portage, making perl module management generally trivial, including uninstall. So when you upgrade from perl 5.8.8 to 5.8.9 or 5.10.0, when they hit the portage tree (5.10.0 is in perl-experimental, though I've not tried it yet), a rebuild of the modules will remove them from /usr/lib/perl5/5.8.8, too.

    If you're using KDE (and this can apply to any Linux, not just Gentoo, though it's more important on Gentoo), check out kio_perldoc. If you're on KDE 3.5, you'll have to install it from the source on the webpage, but if you're on KDE 4.1, you can emerge kde-misc/kio_perldoc. If you're on the alpha of KDE 4.2 (aka 4.1.80), it's been integrated, on all distros, into the core KDE (in the split-build of Gentoo, it's in kde-base/kdesdk-kioslaves). It allows you to read the perldoc from konqueror using "perldoc:/File::Spec", for example. Important on Gentoo where "man File::Spec" doesn't work (but perldoc File::Spec does). (I got the gentoo devs to put it in for KDE 4.0 and 4.1, and reminded the original author to check it in for 4.2.)

    Just my thoughts from running Gentoo for about 3.5 years, on what's now four machines...

[reply]
      Unfortunately kio_perldoc has been masked with the following information: 
      # Jeremy Olexa <darkside@gentoo.org> (02 Dec 2008)
# Removed in 30 days at maintainer's request. No interest and doesn't 
+work with
# newer gcc versions. bug #249308
kde-misc/kio_perldoc

      [download]
      Might be worth some additional investigation before installation!
[reply]
[d/l]
Re: How I fixed it: CPAN crashing on "Uncompress"
by locked_user sundialsvc4 (Abbot) on Dec 16, 2008 at 01:27 UTC

    Thanks. Yes, I actually did know about Gentoo's special tools such as g-cpan, and I do stand corrected about the role of Python (vs. Perl) in that system.

    What makes my situation a little bit different is that, because I do have “all those web sites.” Each one is set up on a local, project-specific user-id whose private CPAN configuration (".cpan" directory) matches the one that's deployed at the web host. Each configuration is self-contained so that it doesn't change, even though the web hosts do update their systems from time to time. (Likewise, it does not change when I update my system from time to time.)

    So, just as I do not have the power to change the site-perl configuration of any web host, I needed to resolve this problem by means other than “re-emerging” (reinstalling...) the global Perl configuration on my box.

    The means with which I did so are like those that would be used at any shared-hosting facility.

    If I did not have this consideration to deal with, then of course this entire issue undoubtedly would not have occurred:   the system-wide Perl configuration (as maintained by “emerge”) was never broken.

Back to Meditations