[Catalyst] Re: list of perl-*.rpm files for a basic Cat install

John Lee jlee+catalyst at pangeamedia.com
Wed Aug 20 16:03:05 BST 2008


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





More information about the Catalyst mailing list