http://www.perlmonks.org?node_id=753416

ELISHEVA has asked for the wisdom of the Perl Monks concerning the following question:

I run a Debian (Etch) machine and normally rely on its packaging system (apt/dpkg) for all of my Perl needs. This has worked for me most of the time, but recently I needed something that was outside of the normal packaging system. I imagine this is likely to happen again, so with the help of my fellow monks, I would like to form an opinion about how to do this safely.

Debian presents special challenges for Perl applications and 3rd party module use (read CPAN) because Debian uses Perl as part of its operating system. To prevent conflicts between the operating system's use of Perl and the Perlish needs of installed applications, Debian has developed a Perl policy (see Debian Perl Policy). This policy defines where the OS and third party applications may place their Perl modules and compiled artifacts.

The Debian team has packaged the most important CPAN modules into .debs and placed them into their repository. These Debian repository modules have been carefully tested for compliance with the Debian Perl Policy. They are generally safe to add to a Debian system. Whenever possible I prefer to use these modules even if they give me less functionality.

Unfortunately, these pre-packaged and well tested modules often have outdated versions of CPAN modules. From time to time I need to use and install newer versions of those modules. This happened recently when I wanted to test the way some in-house software might work with various CPAN modules. The versions in Debian Etch were too out of date to be useful for testing. This left me one of three options:

  1. Use two perls - install a second (non-system) Perl with entirely different locations for its modules. Use only standard debian packages with Perl I (the system perl). Use the cpan command only with Perl II.
  2. Use cpan - carefully. - use the cpan command and hope that the module maintainer is aware of Debian's special needs and has tested their make file so that it plays nicely on Debian. Additionally, take various precautions so that a not-so-nice CPAN module will simply fail.
  3. Use dh-make-perl - download the files from the CPAN repository and wrap them in a debian package. Once wrapped in a debian package, they can be installed like any other normal debian package, via apt-get.

Each of these three has been suggested in recent chatter-box (CB) conversations, and they all have strong proponents. Hopefully, their various advocates will add their responses to this thread so that future seekers-of-wisdom on this topic can read them.

I have reservations about all three, that I would like to discuss in turn:

Option 1: Use two perls - I'm not saying this is a bad idea. I can see lots of situations where this is a great idea. For example, I might need to duplicate the configuration of a clients custom Perl. I can understand rolling one's own Perl if one is setting up a set of virtual machines to test an application on diverse Perl installations. I can see this as a good solution for a webserver where the perl installation is custom fit to the needs of the web site.

But otherwise I don't get it. Building an application that needs a custom Perl to run makes deployment more complex than it already is. Additionally, two Perls does not eliminate the risk of conflicts. As I think moritz pointed out in the CB, two perls can actually increase the risk of conflict if the two Perl's need different versions of a non-Perl non-XS binary library. apt-get which manages the system Perl's (Perl I) needs doesn't know about the dependency needs of Perl II and vice versa.

Option 2: Use CPAN, carefully. Most of the people against this idea worry about CPAN downloading modules that will conflict with the system Perl installation. At least one person (Corion) reported botching his Debian installation due to XS module conflicts between CPAN and the system Perl.

However, there seem to be a number of precautions that can minimize this risk:

  • only install modules in the directories reserved for locally created modules. If I understand the Debian Perl Policy document these are:
    • /usr/local/bin - for scripts
    • /usr/local/man - for man pages
    • /usr/local/lib/perl/version - for modules
    • /usr/local/share/perl/version - for modules
  • To make sure that perl modules are indeed installed locally, set the CPAN::Config option makepl_arg to q[INSTALLDIRS=site] and hope that the make file interprets this properly.
  • But just in case it doesn't, set up permissions to prevent things from being installed in the wrong place:
    • assign these four directories to a dedicated group, e.g. local_admins
    • add users with CPAN installation rights to the local_admin group
  • Finally, never run CPAN as root or as any user that has write permission to any of the directories used by apt-get to install the Debian OS or its optional packages.

If the above precautions were followed, CPAN would simply fail if it tried to install modules (either pure perl or XS) that overwrote modules installed by apt-get. Or at least this is the theory. I would appreciate the thoughts of more experienced monks on this topic.

Of course, one could have two copies of a module, one in the local directory and one installed by apt-get. But that kind of conflict is fairly easy to identify by looking for duplicates in the @INC path or simply by removing the local directories from the @INC path.

Using CPAN carefully, I think would work on a server managed by a system administrator. In our company we use desktop linux and it would be fairly trivial to add the permissions set up to the script we already use to setup and secure desktop systems. However, CPAN can be fiddly. I'm leary of the support issues that would result if I deployed an application that expected desktop users to download CPAN modules as part of the setup routine. Leary, but not against it. A well tested CPAN download script may be all that is needed.

Option 3: Use dh-make-perl dh-make-perl is tool for packaging CPAN modules inside .deb files. The advantage of this approach is that it can be integrated with dpkg apt-get. This makes the CPAN module particularly easy to deploy. It also makes it much easier to monitor what has or has not been installed on a particular system. The Debian packging system has commands that list every package that is currently installed.

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.

If you are still running Debian Etch, there is a second downside. The Debian Etch version of dh-make-Perl doesn't speak to CPAN and so can't automatically follow dependences. You could download everything (module and all dependencies) via cpan get and roll it into one mondo package. But then you have a mondo package. Alternatively you can put everything into separate debian packages and then hand-craft the dependencies into your own debian bundle package. This takes time and is prone to human error. The lenny version of dh-make-perl apparently knows how to follow CPAN dependencies, so this problem apparently goes away for users of lenny.

At present I'm thinking of a two point policy:

  • for modules that are specific to a single developer's work, use cpan configured as above.
  • 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.

So which approach would you recommend and why?

Many thanks in advance, beth

Replies are listed 'Best First'.
Re: What is the best way to install CPAN modules on Debian?
by ikegami (Patriarch) on Mar 26, 2009 at 15:06 UTC

    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)
    • Set makepl_arg to INSTALL_BASE=~ (Alternative for MakeMaker 6.31+)
    • Set mbuildpl_arg to --install_base /home/ikegami (Might accept ~)
    • Add export PERL5LIB=~/lib/perl5 to ~/.bash_profile
    • 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.

Re: What is the best way to install CPAN modules on Debian?
by moritz (Cardinal) on Mar 26, 2009 at 14:50 UTC
    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)

Re: What is the best way to install CPAN modules on Debian?
by JavaFan (Canon) on Mar 26, 2009 at 14:38 UTC
    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).

Re: What is the best way to install CPAN modules on Debian?
by perrin (Chancellor) on Mar 26, 2009 at 15:04 UTC

    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.

Re: What is the best way to install CPAN modules on Debian?
by mpeever (Friar) on Mar 26, 2009 at 14:48 UTC

    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.

Re: What is the best way to install CPAN modules on Debian?
by Herkum (Parson) on Mar 26, 2009 at 16:01 UTC

    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.

    1. Install debian packages first.
    2. If the module is outdated, upgrade via CPAN. Worst case you can delete the files manually and reinstall the debian package.
    3. Install via CPAN. Worst case, you spend time finding the packages that are needed to install the libraries you are going to depend on.
    4. 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.
Re: What is the best way to install CPAN modules on Debian?
by targetsmart (Curate) on Mar 26, 2009 at 14:41 UTC
    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.
Re: What is the best way to install CPAN modules on Debian?
by tomfahle (Priest) on Mar 27, 2009 at 07:21 UTC
Re: What is the best way to install CPAN modules on Debian?
by FunkyMonk (Chancellor) on Mar 26, 2009 at 23:38 UTC
    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:
    1. cd <<cpanplus build directory>>
    2. cpanp t Module::To::Install download & test the module and all dependencies
    3. dh-make-perl --version <<module-version>>-0.0 --build <<directory>> for each directory created by cpanp. (Some fail, and some succeed.)
    4. su -c 'dpkg -i *.deb' Install those that succeeded
    5. 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; }

Re: What is the best way to install CPAN modules on Debian?
by ig (Vicar) on Mar 27, 2009 at 04:04 UTC

    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.

Re: What is the best way to install CPAN modules on Debian?
by dwm042 (Priest) on Mar 26, 2009 at 15:15 UTC
    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.
Re: What is the best way to install CPAN modules on Debian?
by bsb (Priest) on Mar 27, 2009 at 12:48 UTC
    We're starting to use CPANPLUS::Dist::Deb and cpan2dist. It's almost pleasant.
Re: What is the best way to install CPAN modules on Debian?
by hsinclai (Deacon) on Mar 26, 2009 at 19:19 UTC
    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...).

Re: What is the best way to install CPAN modules on Debian?
by doom (Deacon) on Mar 30, 2009 at 19:36 UTC

    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.

Re: What is the best way to install CPAN modules on Debian?
by kubrat (Scribe) on Mar 27, 2009 at 12:15 UTC
    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?
Re: What is the best way to install CPAN modules on Debian?
by zakame (Pilgrim) on May 19, 2009 at 07:31 UTC

    I noticed that the /usr/local hierarchy is group-owned by the `staff' user, so another approach that I'm trying now would be like this:

    1. Make (or add) a user belonging to the `staff' group.
    2. Ensure /usr/local/{share,lib}/perl/$VERSION is group-writeable by `staff'.
    3. Set up CPAN{,PLUS} to disable installing modules as root (even via sudo)
    4. Invoke CPAN{,PLUS} as the user above to install modules.

    So far so good, I have successfully installed the Titanium bundle this way, with the only stumbling being updating the Test::Simple module (which I worked around by running perl Makefile.PL INSTALLDIRS=site). I imagine this may be the case for modules shipped in the Debian perl-base and perl-modules packages.

    A side effect of this is that files of the newly-installed modules will be owned by that specific user in the `staff' group, which is great if you plan to keep you CPAN{,PLUS} installations managed by a single user.

    edit: this is essentially option 2 above, except there's no need to make another `local_admin' group as there's a `staff' group already (designated in Debian as the group for junior sysadmins, see Securing Debian HOWTO)