Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

wirebird (8007)

wirebird
  karen.cravensNO@SPAMgmail.com
http://www.wirebird.com/
Author of Wirebird (also known by its current version, Gamehawk), which is intended to provide separate interfaces to the same community via mailing list and webforum (among others), chiefly because culture clash is fun to watch. Someday I should submit something to CPAN.

Journal of wirebird (8007)

Thursday May 29, 2008
11:13 AM

Someday I should fix cpan

[ #36542 ]

No, not CPAN, cpan... the shell. And just the installation on my server.

See, the server runs Debian, so to keep from stepping on package-managed libraries, we have /opt/perl/lib as an override.

However, for some reason, the cpan shell doesn't find /opt/perl/lib. That is, it quite cheerfully *puts* stuff there, but it won't *use* stuff from there. So when installing, just as a for-instance, Moose, it pops up and complains that I don't have Test::More. Okay, you can install it, I say, and it does.

And then it asks again. No, you can't install it, I say. And it does again anyway, probably because it finally notices that my CPAN::MyConfig says to do so without asking. That's an open bug in Module::Install, which I could live with except it proceeds to install Test::More oh, about a dozen times, sometimes asking, sometimes not.

And then I cuss, because the Moose install itself "fails" for lack of these dependencies, and now I have to do a force install, which is gonna reinstall Test::More and fail to find it ANOTHER dozen times. Yeesh, it's gonna wear a groove in the hard drive there.

Running it with 'perl -I/opt/perl/lib -MCPA..." doesn't help, which isn't too surprising since it's already in PERL5LIB and isn't picking it up from there.

I'm thinking the Perl programs probably wouldn't find Moose &c on their own either, but they all have explicit "use lib"s in there because they're run from users who may not have the appropriate environment set up. So it's probably not actually cpan-shell-specific.

But huh... explicitly editing /usr/bin/cpan to put in the same "use lib" doesn't help. What the heck is it using to (fail to) locate those prereq's? Because makepl_arg is good, and mbuildpl_arg is good.

Is making me crazy.

[Edit: The solution came up via the comments. Turns out that PERL5LIB wasn't being passed, it only looked like it was. "sudo env PERL5LIB=$PERL5LIB cpan" brings it over. Yay! There are also some good and interesting ideas on administering Perl under Debian in there.]


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Someday I should fix cpan 15 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • if you don't mind changing your paths a bit, use local::lib '/opt/perl' and forget about it.

    I'd say you're missing the arch-specific dirs (you probably are), but that can't be all, because that wouldn't explain Moose and Test::More.
    • I don't mind changing my paths inside regular Perl stuff... works good lasts long time already there.

      It's just when I'm sudo'd to run the cpan shell. I can't change root's paths (at least, not permanently) without defeating the purpose of having the libs separated. And even so, I'm doing a straight-up sudo, and PERL5LIB carries over.

      So I'm not at all sure that's the actual problem... it seems like whatever's doing the installation (Module::Install, I think) is failing to locate it internally. Not a failed r

      • And even so, I'm doing a straight-up sudo, and PERL5LIB carries over.

        Are you sure? I believe that by default sudo will clear PERL5LIB because of a security issue [debian.org].

        So, you can either edit /etc/sudoers to keep the value (not recommended) or do something like this. [blogspot.com]

        • I Did Not Know That.

          Neither did my sysadmin/husband (though when I mentioned it, he went off into talking-to-the-ceiling land: "Huh! Yeah, that would... oh, then you could... yeah, that could be a problem... but you could... no... ")

          And hey, passing it on the command line works. Thanks!

      • I don't mind changing my paths inside regular Perl stuff... works good lasts long time already there.

        I didn't mean inside Perl, I meant in your shell, like the local::lib examples give:
        eval `perl -Mlocal::lib=/opt/perl`
        (in .bashrc or similar)

        This will cover all the bases -- Module::Install, Module::Build, your arch-specific dirs, etc.

        • The problem is (was) that Module::Install and everybody all worked fine... *if* I installed manually. There didn't seem to be anything wrong with "my" configuration, I just couldn't figure out why the cpan shell, specifically, wasn't honoring it. So it didn't seem like local::lib would help.

          The key, it turns out, was that by the time I reached "make install," the only bit done with sudo, my personal PERL5LIB had already set all the appropriate paths, so the fact that it wasn't being passed wasn't a concern

  • I've been using Debian for quite a few years now and I've reached the position where I really don't like to install anything onto a machine that's not Debian packaged - if nothing else, it makes it easy to remove stuff :-)

    To build a Debian package from a CPAN distribution, just do something like this:

    dh-make-perl --build --cpan JSON::XS

    This will download the latest tarball from CPAN, unpack it, throw together a skeleton 'debian' directory, and then build the .deb package using the normal CPAN make; m

    • I've done that a little, but I think part of keeping them separate is that then the versions Debian expects are there for Debian-related stuff. But I dunno, exactly. That part's not my bailiwick.

      • In which case, if you are serious about that, you should compile your own Perl from source for use in your code; which would would also mean you wouldn’t have to configure any paths.

        • I have debian (Linux zoe 2.6.24-1-686 #1 SMP Sat Apr 19 00:37:55 UTC 2008 i686 GNU/Linux) and I don't have that problem with cpan, so I've never needed those other manoeuvres either.
        • We've considered that, at least on the dev box.

          I've also considered pretending it's a Windows box: chmod 0777 everything, run as root, and reinstall from scratch every couple of weeks... just so I could ignore OS details until the Perl is finished. And also (okay, mostly) because it's fun to suggest that to a security-conscious sysadmin.
  • Have you solved this issue?

    I don't think there is anything wrong (at least for you) with the cpan script. It looks like you thought PERL5LIB was one thing but it wasn't, and that's why things failed. That's going to be a problem with any Perl script.
    • Yup. The cpan shell just happens to be the only thing I sudo to use, ergo it was the only place PERL5LIB was going away.

      I had thought I had checked it, by su'ing to root and looking at it, and it's properly set there. I didn't realize sudo and su behaved differently in that respect, so I thought I'd eliminated that problem. The fact that that was the only solution I was coming across in Google probably should have told me something, I guess.

  • Have you looked at:

    http://debianpkgs.cpan.org/ [cpan.org]

    for both a mirror with pre-built packages of the most used distributions, as well as tools to build them yourself?

    Integrates nicely with debian and doesn't mess with official packages as provided by the official debian repositories
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.