[oak perl] A good read when loading tricky CPAN modules

[Joe Brenner]

David Fetter <david at fetter.org> wrote:

> Steve Kolupaev wrote:

> > "Problematic perl prerequisites - O'Reilly Sysadmin" -  Chris Josephes
> >
> > http://www.oreillynet.com/sysadmin/blog/2008/01/problematic_perl_prerequisites.html
> >
> > This is a good discussion of the difficulties we sometimes have
> > when loading a  new CPAN module.   It is well written with
> > numerous well-written replies.
> >
> > I would recommend reading it when perl -MCPAN -e'shell', or
> >
> >    perl Makefile.PL
> >    make
> >    make test
> >    make install
> >
> > sends you out into the jungle with multiple levels of prerequisites.

> As the replies state, in a system with packages, i.e. all the modern
> ones, this is precisely the approach you *don't* want to take.

Actually, that's not exactly true.  Cromatic's remarks are a
little more neutral on the subject, for example:

 "If you don't use CPAN.pm to install these modules,
  you're at the mercy of your packaging system."

> Systems like yum and apt are designed to handle dependency issues, and
> if you decide to pry up this cover plate by ignoring the packaging
> system, you risk ruining the entire machine.

For various reasons, that seems like an rather small risk
where upgrading a perl module is concerned.

Now, certainly, upgrading the perl binary that your system
depends on would be rather foolhardy.  But because of that, I
would guess that all serious perl users end up with at least
two versions of perl running in tandem... and when you
upgrade a perl module, you're most likely upgrading the one
that your /usr/local/bin/perl (or whatever) sees, not the
/usr/bin/perl.

> For those times when you find a Perl module *not* listed in your
> favorite package repository, you'll be doing a great service to your
> community by packaging them and submitting them to that repository.
> Yes, I know it's more work to create a good package, but it's
> instantly useful to your whole community, not just to you. :)

That's certainly a point, but the reason I'm inclined to use
CPANPLUS.pm (now a core module with perl 5.10) has more to do
with prefering the latest versions that exist out on CPAN,
rather than the versions that were fixed in place with my
disto's release.

In any case, either way you choose to adopt as policy, there
are existing methods of automatically satisfying dependencies.
If you're still manually chasing down prereqs then either
you're doing something wrong, or you've turned up some bugs
in package dependencies that you need to report.