Aristotle Pagaltzis wrote: > Point taken; the usual advice of compiling Perl and running a > vetted CPAN mirror is motivated by the more common situation > where the number of large Perl apps to run, which tend to be > sensitive to module versions and may each require a different > version of the same module, is not a priori bounded. Trying to > handle that situation via the package manager of the distro is > asking for the impossible. > > If you have a large number of boxen and only a bounded and small > number of Perl apps to support, then using the package manager is > a more sensible proposition, but few people are in that position.
To provide one other perspective on this... I found it convenient to package Perl in .deb files on Ubuntu. It actually can support dependencies on specific package versions or package version minimums. There's no good automated way of building packages (dh-make-perl notwithstanding), but it can be done and giving everything a once over is probably a good idea. Having them in packages is also convenient because then if I need to do a new deployment, I can build a package list, and use that for Perl module installation. I build a local repository and give developers access, so they can get any modules I build, rather than relying on them to install them all on their own. I can also be sure that the versioning across the entire system is the same, because they just pull package updates. And yes, it does have drawbacks: * Upstream providers will sometimes over-package modules, which can resuilt in conflicts when building new ones. (perl-modules and libcatalyst-modules-perl come to mind.) One can either build their own to replace, or "force" overwrite it. * No easy way of applying CPAN updates (yet). I manually scan an RSS feed and consider upgrades, but there's no easy way to vet it. (This is a terrible solution, I just haven't come up with a better one yet.) * Doing the work of CPAN yourself. You're essentially doing a lot of the work CPAN would do for you (finding and building dependencies, especially). * I sometimes end up building the same module a couple times for different architectures (amd64 vs. i386). _______________________________________________ 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/