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

[David Fetter]

On Wed, Jan 23, 2008 at 08:34:22PM -0800, Joe Brenner wrote:
> 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."

That's not exactly a "neutral" tone.  It's the tone of a guy who
doesn't trust his packaging system, or really enjoys fiddling with
dependencies. ;)

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

It may be, or it may not--depends on what other things in your system
depend on Perl modules.  However, just generally, it's easier just
never to end-around your packaging system than to have some byzantine
decision-making process about the circumstances under which you're
going to.  Then there's documenting what you've done so others will be
able to follow it...

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

I guess I'm not macho enough to run multiple versions of perl on my
system.  Haven't needed to be yet.

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

You seem to be assuming a fixedness to these versions that is counter
to my experience.  When you issue a "yum update" or equivalent in
other packaging systems--a very good idea to do regularly, given that
many upgrades fix known remote vulnerabilities--you get the latest.

And again, if it isn't the latest, tools like cpanspec can get you a
long way in the right direction to making the latest available to
everybody :)

> In any case, either way you choose to adopt as policy, there
> are existing methods of automatically satisfying dependencies.

Yes, and the best ones play nice your packaging system :)

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

Yep.

Cheers,
David.
-- 
David Fetter <david at fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter at gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate