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.]
Re:local::lib
wirebird on 2008-05-29T17:57:05
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 require, but a "can't find this file in the filesystem" sort of search. Which makes no sense: it knows where to *put* the stuff, why does it not try looking there?
I suppose the cpan shell doesn't use any non-core modules, so I can't really tell if it would successfully find them for actual use. Almost makes me want to move something essential to the/opt directory, except then the mail server or something would probably explode.
Re:local::lib
phillup on 2008-05-29T19:39:56
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.
So, you can either edit/etc/sudoers to keep the value (not recommended) or do something like this. Re:local::lib
wirebird on 2008-05-29T20:15:46
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!
Re:local::lib
hdp on 2008-05-29T21:18:15
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.
Re:local::lib
wirebird on 2008-05-29T22:08:09
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 anymore.
My bash-fu is weak, so I don't know if local::lib would get around that similarly... I'm fuzzy on when sudo actually switches users. (My CNFIGSSP-fu is strong, though. So there.)
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
It won't work for every CPAN distribution, but often you can 'cd' into the unpacked directory, resolve the obvious problem and then run:
dh-make-perl --build.
The major advantage of all this is that if you build the package on your development environment then you know that deployments to staging and production enviornments will use the exact same version you devloped against.
Re:Have you tried dh-make-perl?
wirebird on 2008-05-29T21:36:17
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.
Re:Have you tried dh-make-perl?
Aristotle on 2008-05-30T03:31:09
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.
Maybe it's (shudder) something you've done?
Ron Savage on 2008-05-30T07:50:42
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.Re:Have you tried dh-make-perl?
wirebird on 2008-05-30T12:42:15
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.
Re:So, no problem with cpan?
wirebird on 2008-05-30T12:33:10
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.
Re:Just a thought...
wirebird on 2008-05-31T02:27:57
http://debian.pkgs.cpan.org/, actually, and no, I hadn't.
Innnnnteresting. I'll throw that at my sysadmin. Thanks.
