[Catalyst] Re: Debian recommendation

[Daniel Pittman]

Octavian Râşniţă <orasnita at gmail.com> writes:

G'day Octavian.

> I've seen a recommendation on this list for Debian for running perl apps,
> and recently I started to use this distro.  I've seen that I can install
> perl modules very hard under Debian if I use the CPAN shell.

If you forgive me descending into opinion, I think you are approaching this
from a point of view that will make Debian, more or less, unhelpful to you.
Installing Debian, then putting everything else in place from CPAN (at least
system-wide) is going to cause problems in the longer term.

Debian has two key advantages over distributions:

1. It has a long "stable" release cycle, and strong assurances of security
   during that cycle.

2. It has a very big pool of packages (2,065 Perl libraries, presently)
   compared to many of the other distributions.


The first means that you can safely keep updates in place and be confident
that your system will stay working; this includes Perl modules that have
security issues and the like, because Debian work very hard to backport
security fixes to the same module version.

(OTOH, it is also a drawback: if Debian/stable ships with version 1.23 it will
 still have version 1.23 two years later.)


The second means that you have a huge selection of code that you know is going
to work together, effectively, and be supported by someone else.  If security
issues come up, or a library changes incompatibly or whatever, Debian look
after it for you.


If you just install from CPAN directly then you lose those values: Debian
don't do security stuff on your CPAN installed code, so point one is lost.

You also don't get the compatibility stuff: the Debian packaging
infrastructure and CPAN are not directly integrated, so you can't use a CPAN
installed module to satisfy a Debian Perl dependency.

That means that you actually have to do /more/ work if you upgrade an existing
module under Debian with CPAN, not less, which /really/ misses the point.


So, I strongly advise that for, say...

[...]

> cpan> install Class::MOP

...this, you instead use 'aptitude install libclass-mop-perl', which uses the
Debian supplied version of Class::MOP.  Then you can work with that specific
version in your software, and know that for the next few years it will stay
secure and stable.


If you do need packages outside those in Debian, or to upgrade a Debian
supplied Perl package, the best strategy is to build a platform package from
the CPAN distribution, and manage it with the Debian tools — not the CPAN
tool.

There are a bunch of ways to do that, including dh-make-perl, dh-make,
CPANPLUS::Dist::Deb, and hand-packaging[1].  Then, shove those hand-made
packages into your own private Debian package repository, and it integrates
nicely into the tools and everything.


If you do just want to use cpan directly, either use local::lib, or use a
distribution that makes direct installation from CPAN the standard mechanism
for getting access to Perl.

I understand that the BSDPAN tool, in *BSD ports, as well as Gentoo, offer
very good tools in this regard, certainly better and easier than the Debian
tools.  I can't say much more, though, because I don't have enough deployment
experience with them to comment — and there are doubtless other platforms that
make CPAN(-alike) tools easier to integrate with the distribution.

Regards,
        Daniel

Footnotes: 
[1]  This is probably surprisingly easy, actually, since CPAN packages are
     simple to configure, build and install, so Debian packages of them are
     correspondingly easy.  Go Perl!

-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons
   Looking for work?  Love Perl?  In Melbourne, Australia?  We are hiring.