I use Debian, and I use an option you didn't list. I use the system Perl (threaded 5.8.8), and I install all my packages in a fresh directory using cpan (although using cpan is not required). Set makepl_arg to PREFIX=~ LIB=~/lib/perl5 (Any version of MakeMaker)

to (Any version of MakeMaker)

Set makepl_arg to INSTALL_BASE=~ (Alternative for MakeMaker 6.31+)

to (Alternative for MakeMaker 6.31+)

Set mbuildpl_arg to --install_base /home/ikegami (Might accept ~ )

to (Might accept )

Add export PERL5LIB=~/lib/perl5 to ~/.bash_profile

to

Run mkdir -p ~/.kde/env && ln -s ~/.bash_profile ~/.kde/env/profile.sh (For KDE console login) (The following setup uses ~ , but you can use any directory. I don't know the equivalent of the last for gnome.) I haven't had any issues yet.

I think it was JavaFan who told me he uses the idea of having cpan installation dirs writable by a special group, and told me it worked fine. Maybe we'll hear from him... (Update: he was even faster than me... read for yourself :-) However, there is still a downside. Unless I am missing something in the documentation (am I?), the debian package simply calls the CPAN modules's own make files. That means that you are still dependent on the quality of the CPAN module writer's build scripts. If they have put in something that conflicts with the system Perl, one has the same problems as one would have downloading directly from CPAN. First of all let me clarify that it does call the Makefile of the package via make install , with a special path prefix. I usually run dh-make-perl under fakeroot , so that it does no damage to my system if something is accidentally written to the wrong location. There is a still the conflict with core modules, or for example when installing TAP::Parser 3.0 (I think) on Debian Etch it conflicted with perl core's prove utility. That's something that you can only avoid by using a separate perl installation independent from the system perl. On my desktop I usually go the dh-make-perl route, and sometimes install a blead perl in /usr/local/ for testing. When I ran /usr/local/bin/perl -MCPAN -e shell I never had problems that modules where accidentally installed into / or /usr/ instead.

I think it was JavaFan who told me he uses the idea of having cpan installation dirs writable by a special group, and told me it worked fine. Actually, I use a special user (usually I call the user perl , camel or onion ). But then I use said user to install anything Perl related - I never tried installing half of it as root, and the other half as someone else. About the only module that requires an additional step when installing is Tk on the local machine while using sudo su - xxx to switch users; I don't allow others to open windows on my X client, and hence Tk's test will fail when run as a different user. Running xauth fixes that. But none of that really relates to what the OP wants to do, so I didn't mention it.

I don't allow others to open windows on my X client, and hence Tk's test will fail when run as a different user. Running xauth fixes that. i use ssh -X for that. e.g. 'ssh -X otheruser@localhost' or 'ssh -X otheruser@remotehost'. it's the least hassle way of allowing other UIDs temporary access to my X server. oh, and as for the original thread topic - i use dh-make-perl, and have done so for many years without problem. For a systems administrator, if not for a programmer, it is THE best way to use non-packaged CPAN modules and still have a consistent environment across hundreds of systems. package it once on your fastest/best dev box and ship it out using scp and install with dpkg (or, if you're doing it a lot, make your own apt repository for your local packages)

If 2) depends on modules authors catering for Debian, I wouldn't use 2). We have all those lovely tools to make CPAN packages, and to download them so module authors do not have to care about the gazillion ways CPAN modules can be installed. I'd go for 1) if Debian has made that easy. Solaris used to do this right (and probably still do, but I don't have access to a recent Solaris at the moment to verify). Solaris also has tools using Perl. /usr/bin/perl is a link to /usr/whatever/perl . Solaris specific tools start with #!/usr/whatever/perl . This means that if one doesn't install their own perl, one can use #!/usr/bin/perl (because a perl is there). But it also means one can install a /usr/bin/perl without breaking the system tools. If Debian does the same, I'd certainly go for 1). Otherwise, I probably would go for 3).

I've done all of these. The primary reasons to build your own perl are to use your own compile options (so you can turn off threads, for example) or to avoid Debian auto-upgrading a module you depend on. If neither of those concern you, making packages with the script you mention or the one in CPANPLUS seems good because you can uninstall them. The problem you'll encounter is that some modules have build scripts that are hard to deal with, but there's no way around this.

I've had similar problems with OpenBSD. And Solaris is even worse, as it doesn't come with a C compiler. I tend to favour the dual Perl approach, but I largely work in a server environment. As you have pointed out, that makes a huge difference: code (whether Perl or otherwise) is not so much run on a server as it is added. It's trivial to start a script with #!/usr/local/bin/perl on a server. It gets enormously harder when the script is to run on machines outside the sysadmin's (or the sysadmin's team's) control. A solution I have commonly seen is to simply not use CPAN modules. I know that goes against all the "best practices" ever published; but several sysadmins I know have decided it's better to re-invent the wheel than to jeopardize a running system with 3rd-party code that typically comes without warranties. In fact, one friend of mine is a sysadmin in a finance company, and there are policies in place explicitly forbidding the use of CPAN modules. I hate to say it, but there is a lot of merit in that approach. And if there are issues with distributing code across a number of machines because of CPAN dependency issues, re-inventing the wheel is a very reasonable option. I've moved to a much more relaxed environment (and the lower pay that goes with it) in the last 8 months. It's been nice to use CPAN again without having to justify it to everyone and their dog.

In fact, one friend of mine is a sysadmin in a finance company, and there are policies in place explicitly forbidding the use of CPAN modules. We have a ban on modules we can't receive from Debian's package manager, so I take the CPAN module and drop it into my project. Now it's no longer a CPAN module :) I work on projects used internally, so the license is not an issue. This way, we test against the same version of the module that ends up being used. It also gives us the ability to make and track changes to it, if need be.

We have a ban on modules we can't receive from Debian's package manager, so I take the CPAN module and drop it into my project. Now it's no longer a CPAN module :) I work on projects used internally, so the license is not an issue.



This way, we test against the same version of the module that ends up being used. It also gives us the ability to make and track changes to it, if need be. This sounds like a good, simple solution, but isn't it a bit of a problem that the CPAN module can't receive any updates unless you decide to apply them? It takes the process of doing updates out of the domain of the sysadmin's and leaves them up to the programmers.

one friend of mine is a sysadmin in a finance company, and there are policies in place explicitly forbidding the use of CPAN modules. I hate to say it, but there is a lot of merit in that approach. No, really, there isn't. Wherever possible, risks should be managed, not simply avoided. And CPAN is a manageable risk. A policy that does have merit is "no unaudited CPAN modules". It makes sense to control the code coming into your systems; it makes sense to check the licenses and to perform due diligence in (for example) looking at the bug trackers, reading module reviews, looking over the code for nasty smells, and finally installing the code on a development server and checking that it isn't likely to break anything in the operational environment. And, of course, it makes sense to require people to present a good business case before you allocate the resources to do all that work. It does not make sense to automatically reject all third-party code. You will waste time and money reinventing wheels. Has that place seriously even written their own versions of stuff like DBI?! If so, they'll have ended up with something that probably contains more bugs, performs worse, and behaves differently from the standard interface that everyone else in the world uses. And to this day they'll be wasting even more time and money maintaining it themselves, instead of letting other people take care of that while they put all their resources into doing their core business well. This is not the path of merit.

It does not make sense to automatically reject all third-party code. You will waste time and money reinventing wheels. Has that place seriously even written their own versions of stuff like DBI?! I'm only passing on what I've been told... It's hard to imagine a profitable company in an extremely competitive and fast-paced business that doesn't have a protocol for working around policies where they are counter-productive. I assume there is a process in place whereby CPAN code can be vetted, tested, approved, and added to some sort of whitelist. The immediate effect on my friend, however, is that he can't search CPAN whenever he runs into a wall with his Perl. When he calls to bounce ideas off me, he generally adds the caveat: "I can't use CPAN." If we imagine a company with even the most stream-lined vetting process, we still end up with a scenario where a sysadmin's one-off monitoring script becomes a several week effort while he waits for approval for that module. Home-rolling is faster. Even with intense testing and debugging, it'll get the code across the finish line before a module passes review; and a sysadmin doesn't care about portability: the code she is writing has to run on a very specific platform. That removes a huge amount of effort that goes into anything on CPAN. People in that environment aren't writing frameworks. As far as I know, neither my buddy's employer nor I have ever advocated re-writing a generalized framework like DBI. That's what Paul Graham calls a "pathological edge-case." In a case where sensitive data is potentially exposed, or where loss of service is measured in millions of dollars per hour, the loss of developer and/or administrator time re-inventing a lot of wheels is negligible by comparison. Additionally, in-house code doesn't have to be portable: operating platforms are concretely known and change very rarely. From a coder's perspective, using 3rd-party modules makes a lot of sense. But there are business scenarios where it's just not the right thing to do. And in some cases, it's been decided to reject foreign code by default for very sound business reasons. That's my only point.

And Solaris is even worse, as it doesn't come with a C compiler. SUN no longer ships gcc with Solaris 10? Are you sure? It may not be installed by default, but SUN used to ship a set of GNU software on their Solaris installation CDs, including gcc .

You are correct in thinking that Sun does still ship gcc with Solaris 10 and it can be found on the "Software Companion" CD. The version is 2.95.3 which is hardly recent but you can find version 3.4.6 on http://www.sunfreeware.com/. Cheers, JohnGG

Doh! I forgot the GNU companion CD. I always use http://sunfreeware.com/ instead. Still, I've had issues getting the installed Perl to play nicely with gcc on Solaris. I just started building a parallel Perl system under /usr/local when I set up new systems. Is it just me? I've booked a lot more time on Solaris 8 & 9 than 10, so perhaps my information's outdated.

I am using Ubuntu and I have come across the same problems. If your lucky the module is already bundled as a package and you can install that. If not, I try to use CPAN. The problem is sometimes finding all the dependencies(underlying libraries) to get packages installed can be difficult. I have also installed a separate version of Perl due to a Class::Std problem with the default system build. Luckily my application had relatively few library dependencies but sometimes you are still stuck trying to identify and install the correct libraries for modules. My recommendation. Install debian packages first. If the module is outdated, upgrade via CPAN. Worst case you can delete the files manually and reinstall the debian package. Install via CPAN. Worst case, you spend time finding the packages that are needed to install the libraries you are going to depend on. Extreme case, you have no options, install a separate version of CPAN. Change the search path for the account(s) that will use the newer version of Perl. God knows what you would break if you replace the default perl executable.

There are two more options not mentioned in this thread: debian.pkgs.cpan.org -- debified CPAN packages, all the work is already done for a lot af CPAN-Modules



cpan2dist $ cpan2dist --format CPANPLUS::Dist::Deb --buildprereq Desired::CPAN::Module Hth,

Thomas

for modules that need to be deployed across an organization, inspect and test the CPAN module carefully for conflicts. If the build file is OK, use dh-make-perl to bundle up the package for installation. Otherwise patch the make file, and then use dh-make-perl. ya true i use lot of CPAN modules which is not listed in Debian package repository like Asterisk::Manager, etc

but I test it rigorously and third party testing also will be done on the code before getting deployed, moreover we used to give OS and the same perl(5.8.8) also with code to clients so it becomes easy.

I haven't used dh-make-perl file much, but I will try to use it henceforth.

Vivek

-- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.

I use Debian/testing aka squeeze and I've got ~300 non-Debian CPAN packages installed, all as .deb's using dh-make-perl. FWIW my workflow{1} is: cd <<cpanplus build directory>> cpanp t Module::To::Install download & test the module and all dependencies dh-make-perl --version <<module-version>>-0.0 --build <<directory>> for each directory created by cpanp. (Some fail, and some succeed.) su -c 'dpkg -i *.deb' Install those that succeeded Repeat 3 & 4 until all the modules are installed It's a long way from being perfect, but it works for me. {1} Scripted, of course: #!/usr/bin/perl use 5.010; use strict; use warnings FATAL => 'all'; run(); sub run { fetch_and_test($_) for @ARGV; for my $dir (grep -d, glob "*") { system qw[rm -rf], "$dir/debian" if -e "$dir/debian"; my ($module, $ver) = $dir =~ m/(.*)-(.*)/; my $deb = lc "lib$module-perl"; system(qw/dh-make-perl --version/, "$ver-0.0", "--build", $dir + ) == 0 and system qw/rm -rf/, $dir; #created a deb } } sub fetch_and_test { my $module = shift; system qw[ cpanp s conf prereqs 1; ], "t", $module; } [download]

Another option is to install modules into application specific libraries. I have systems running multiple perl applications, each with its own module requirements. While the modules installed on the system are usually adequate, sometimes newer or older or patched versions are required for a particular application. To avoid adversely impacting the system or other applications, I prefer to install such modules into an application specific library - just a few more modules among the application's own modules. I am currently investigating options for cpan and cpanplus to have them use application specific configurations rather than the system wide or personal configurations. I don't see easy support for this out-of-the-box, so I expect I will customize cpanplus to make installation and maintenance of these modules easier.

ELISHEVA++, it's a great question. And at the risk of piling a question on top of a question, does Ubuntu have the same issues?

Yes, Ubuntu has the same problem. After a dreadful headache trying to get mod_perl2/Apache2/MySQL set up and failing on obscure package problems...I went with Option 1.

We're starting to use CPANPLUS::Dist::Deb and cpan2dist. It's almost pleasant.

4. Use CentOS/RHEL



I'm not trying to be cheeky - I realize it won't be possible for people to just replace a Debian/Ubuntu server at their company.



Using CentOS and RH systems since 2005, though, I have not encountered any of these problems - being a sysadmin - I mix system Perl, CPAN, dag/apt modules all over the place and they all seem to get along fine.. these are mostly all Perl 5.8.8 BTW, so that will probably make a difference as well as Debian's kernels and libs are more recent which might be having some impact on what problems people are seeing in this regard..



Then again I may not have many modules installed where the XS dependency is critical - what are some of those? (so I can test.. thanks..)



FreeBSD removed Perl from the base system requirements and moved it to ports a while ago ... smart.





I'm sorry, and I'm not trying to be difficult either, but Red Hat & Cent are not the poster children for ideal Perl operating systems. Then again, neither is Mac OS X. This sort of thing is why I prefer to build my own. At least that way, I know where to find the idiot who screwed things up.

Hm, that bug was addressed, at least on CentOS 5.2 by Karabir Singh and RH released a fix too - 18 months ago... I saw that blog when it originally came out.



I just want to emphasize that I (emphasis on "I") have not seen the module compatibility problems mentioned in ELISHEVA's original post here, since 2005 and Centos4.4 ..





Using CentOS and RH systems since 2005, though, I have not encountered any of these problems - being a sysadmin - I mix system Perl, CPAN, dag/apt modules all over the place and they all seem to get along fine.. And I do the same on my Debian and Ubuntu boxes. You really can just ignore this issue and you'll most likely be fine... but there are odd cases where you might be burned which you (and I) haven't run into yet. It really is unlikely that CentOS/RH have some magic solution to these problems (after all, the usual state of affairs is for RH to imitate Debian five years later...).

What is the problem exactly? I have used Debian for years and whenever a module is not in the Debian repositories or it is not the version I require I just used CPAN to install it. And I have never ever had any issues. cpan installs in the same @INC folders as the debian packages do, so what difference does it make where the module comes from?

I like the variant of (2) that uses special locations in /usr/local for all CPAN installation. This sounds like the easiest way to cover any possible problems, and I suspect that CPAN.pm and CPANPLUS.pm already do this by default (see below). Technique (1) on the other hand strikes me as very generally useful: it might be more work, but once you've mastered those techniques you'll find other uses for them (like, for example, you want to try upgrading from perl 5.8 to 5.10 for the production code, but leave 5.8 in use for the system code). Technique (3) is very Debian/Ubuntu specific, and at a guess is only worth hassling with if you're interested in getting involved with helping the Debian project by maintaining debs of perl modules. What I actually do, however, is ignore the problem: I install a bunch of debian/ubuntu perl packages, but whenever I'm so inclined I do installations and updates via CPAN.pm or CPANPLUS.pm. I realize it seems like living dangerously (how do I know an "apt-get upgrade" won't downgrade something important?) but I've yet to run into any difficulties like that. Taking a look at my @INC, I see I've got a rough order of precedence of dev, local, and system locations. Maybe that's a policy that helps. I just experimented with installations via CPAN.pm and CPANPLUS.pm, and I see they both install in /usr/local/share -- it could be I've got method (2) covered already without realizing it. There's nothing special in my ~/.cpan/CPAN/MyConfig.pm that does this, so it would seem that CPAN.pm/CPANPLUS.pm do the Right Thing by default. This is an experience I've been having lately with perl, by the way... I start worrying about some issue, dig into it, and I find that it's largely a non-issue because someone else did something intelligent a long time ago.