Paul Makepeace <pa...@paulm.com> writes: > On Fri, Oct 16, 2009 at 7:01 PM, Daniel Pittman <dan...@rimspace.net> wrote: >> Octavian Râşniţă <orasn...@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 ✉ dan...@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons Looking for work? Love Perl? In Melbourne, Australia? We are hiring. _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/