Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

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

In reply to What is the best way to install CPAN modules on Debian? by ELISHEVA

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (3)
As of 2024-06-25 00:15 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.