[Catalyst] Re: Debian recommendation

[Daniel Pittman]

Paul Makepeace <paulm at paulm.com> writes:
> On Fri, Oct 16, 2009 at 7:01 PM, Daniel Pittman <daniel at rimspace.net> wrote:
>> Octavian Râşniţă <orasnita at gmail.com> writes:
>>
>> > 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.
>
>> 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.
>
> I recently have completely tossed using Debian's perl packages because,
> while I do love Debian and all its package awesomeness, there simply wasn't
> the package lib*-perl support in stable/lenny and even testing/squeeze
> didn't have all the goods needed for a (what I think is) fairly regular
> Catalyst install.

Presumably the packaged Catalyst wasn't sufficient either. ;)

> So my question then is: given you've presumably done this, which of your
> quoted solutions do you like best? I tried dh-make-perl many moons ago and
> gave up due to annoyances around following dependencies.

dh-make-perl or debhelper (>= 7.0) are the nicest options, in terms of package
quality, but don't do anything about following dependencies.

dh-make-perl was unmaintained and awful in earlier releases; Lenny is better,
and Sid (unstable) better still, but they are still not /great/.

CPANPLUS::Dist::Deb is the easiest, but has some quirks; the biggest is that
it doesn't check if a packaged-but-not-installed Perl module meets a
dependency.


Anyway, if it helps: the best answer is to hand the maintenance of the
infrastructure to an appropriate expert in the company, and work with them.

That may mean Debian packages, or something else, and it probably /also/ means
that you can't just deploy the latest CPAN everything — which, yes, is a
trade-off on all sorts of levels.[1]

> I'm hoping local::lib + cpan + git solves this but curious how
> Debian-integrated solutions work too.

If you do want to go the Debian route, you are going to need someone who has a
reasonably deep knowledge of Debian Perl packaging at some point, sadly.[2]

I generally consider using the dh-make-perl / debhelper 7 tools and manually
following dependencies to be a reasonable strategy.  This is more work, but
results in better considered and higher quality outcomes.

(case in point: JSON 1 vs JSON 2, with their incompatible API.  If you don't
 pay attention, upgrading can break other application deployments.)


FWIW, local::lib (or the hand-rolled equivalent) is probably the best strategy
I can identify for addressing this with the ability to use random CPAN stuff,
without breaking other applications, and without the overheads of central
management.[3]


...and, again FWIW, my original point was not that the Debian approach is
necessarily the best approach, but rather than Debian won't return nearly the
same value if you don't accept the costs of their approach. :)

        Daniel

Footnotes: 
[1]  ...and, yes, I do get annoyed by this when I wear a developer hat and
     all.  Heck, for my own local utilities have something like 60 or so Perl
     modules hand-packaged on Debian/unstable.  (Down from 80, because
     apparently upstream Debian/perl people have the same taste in CPAN
     modules that I do, so they keep packaging them for me. ;)

[2]  I strongly suspect this is true of cpan2rpm, and BSDPAN, and the Gentoo
     tools also, but I have not used them hard enough to find out.

[3]  I don't think this is actually worth the trade-off in the longer term,
     since you now have to address questions like deploying bug-fixes in
     modules for every application (server) independently, but YMMV.

-- 
✣ 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.