Your skill will accomplish
what the force of many cannot
What is the best way to install CPAN modules on Debian?by ELISHEVA (Prior)
|on Mar 26, 2009 at 14:24 UTC||Need Help??|
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:
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:
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:
So which approach would you recommend and why?
Many thanks in advance, beth