Re: [Catalyst] Re: Debian recommendation
Paul Makepeace wrote: 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. ++ here. I had to build a lot of missing modules, or upgrade modules, that we wanted / needed. I actually didn't mind the headaches of chasing down dependencies when building my own packages using dh-make-perl, because it made it so much simpler system-side to distribute libraries (with dependencies!) with apt-get installs. The roadblock came when the packaged perl libraries needed to be upgraded in a manner inconsistent with the platform. For example, running perl 5.8.8 in an Ubuntu LTS installation, when you wanted features found in perl 5.10.0. When I started getting blocked on upgrades due to conflicts with, say, perl-base and perl-modules, or requirements for libperl5.10, I scrapped it and went with a source-built perl and CPAN. I even went through the process of creating updated perl, perl-base, and perl-module packages based on 5.10, but eventually, systems dependencies on the old version catch up to you. 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. Maybe CPP::Dist::Deb or something else solves that. I didn't give CPP a try, but I had a lot of experience with dh-make-perl. I found that it gave you a good start, but you have to be anal about creating packages for dependencies and setting descriptions. I'm hoping local::lib + cpan + git solves this but curious how Debian-integrated solutions work too. I'd be curious to see if this works well for folks too! I'm especially interested in folks who do this with a perl installed to a separate location, e.g. /usr/local/bin/perl. I worry about things like C library dependencies (ImageMagick comes to mind). - John ___ 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/
[Catalyst] Re: Debian recommendation
Octavian Râşniţă orasn...@gmail.com writes: From: Daniel Pittman dan...@rimspace.net Octavian Râşniţă orasn...@gmail.com writes: As a side note, Octavian, your mail client didn't quote any of my text, which made it quite tricky to work out what you and I both said. ;) 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. Yes I think you are right. I think I would like a distro that allow me to install packages like libpng, libgd and others like these very easy, like yum and apt-get do, but also let me install perl modules with cpan because no distro's repository would be as well updated as CPAN directly. The solution seems to be to use Debian and install perl modules using local::lib. *nod* That, or perhaps investigate something with a ports-alike system, either on *BSD, or Gentoo, or perhaps some other Linux distro. Now, I've started to use a fresh installed Debian and I've installed very many CPAN modules using CPAN in the default perl modules location. What would you recommend me to do in this case? Can I just rename/delete the files and dirs installed into /usr/local/share/perl/5.10.0 and install them using local::lib? If you installed all the modules under /usr/local then you should be pretty OK; Debian deliberately keep that for local software installation, so no package will put things there. You could even keep installing things there if you want; it won't *break* anything — it just won't give you too much value from the Debian part of the equation either. ;) At this point I would suggest one of two things: 1. Delete /usr/local/share/perl/5.10.0/* entirely, and use local::lib 2. Just keep using /usr/local to install stuff system-wide, and accept that this is potentially going to make the wonderful stuff people say about Debian less applicable to your machine. Daniel -- ✣ 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/
[Catalyst] Re: Debian recommendation
Octavian Râşniţă orasn...@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✉ 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/
Re: [Catalyst] Re: Debian recommendation
On Fri, Oct 16, 2009 at 7:01 PM, Daniel Pittman dan...@rimspace.net wrote: Octavian Râşniţă orasn...@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. 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. 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. Maybe CPP::Dist::Deb or something else solves that. I'm hoping local::lib + cpan + git solves this but curious how Debian-integrated solutions work too. Paul ___ 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/
Re: [Catalyst] Re: Debian recommendation
On Sat, Oct 17, 2009 at 12:33 PM, Paul Makepeace pa...@paulm.com wrote: 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. 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. Maybe CPP::Dist::Deb or something else solves that. I'm hoping local::lib + cpan + git solves this but curious how Debian-integrated solutions work too. Paul I would have to agree with Paul here. I went the dh-make-perl CPANPLUS::Dist::Deb routes, had my own repositories and packaged my own modules as debs. I basically found it complicated everything too much for my liking. I pursued this for quite a while knowing Debian used Perl extensively in it's own admin scripts and messing with them carried the threat of screwing with more than my own stuff. I encounted repeated issues with the automated packaging systems and more trying to manage my own repository. I currently have cpanp configured on my servers so I can install modules to a user's home directory. I then modify other users' .bashrc to add that directory to inc. Getting cpanp configured and set up this way has proved to be tricky so in future I will be trying the local::lib method. I love Debian and settled on it as my dist of choice many years ago but wanting to use the latest greatest Perl modules means not sticking with 100% Debian packages. Catalyst DBIx::Class (as examples) move way too quickly for that and the benefits that the latest versions offer are often too good to refuse. I still use aptitude as my first port-o-call for installing Perl modules whenever I can but when that fails cpanp easily picks up the slack and as a last resort I can always use cpanp as root. I've been running like this for a year or so now and in that time I haven't had to spend more than 10 minutes ugrading or installing any module I've needed. ..just my 2c cheers, J -- Jason Galea Web Developer Ph 07 40556926 Mob 04 12345 534 www.eightdegrees.com.au ___ 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/
[Catalyst] Re: Debian recommendation
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/
