Re: yast vs cpan

More than likely they'll install to the same locations, so yes there could be problems if you try to install the same modules different ways.

Pros and cons would be:

Using the OS' package management would give you an uninstall mechanism
It may be slightly easier to use the OS' package manager to install the same set of packages on large numbers of machines
You're likely to get more timely updates to packages going straight from CPAN (i.e. you're at SuSE's mercy waiting on them to package a new release; or you'll have to roll your own local package)
You're likely to get a wider selection of modules straight from CPAN (you may need Some::Obscure::Module that isn't going to be packaged because there's 7 people on the planet using it)

There's probably more, but that gives you some sort of an idea. It's similar to any other "use OS' package management" versus "compile from source myself" decision.

Update: Very good followup below by Anonymonk, especially the one about compilerless boxen.

Comment on Re: yast vs cpan

Replies are listed 'Best First'.

Re^2: yast vs cpan
by Anonymous Monk on Nov 10, 2006 at 09:39 UTC

CPAN can only solve dependencies on other CPAN modules. The package manager of your OS can solve other dependencies as well (a C library for instance).
The package manager or your OS (well, at least most of them) can list which files belong to a certain package, and, given a file, list to which package it belongs. That's much harder with CPAN.
The package manager of your OS will usually have pre-compiled binaries available (XS modules in case of Perl). Installing from CPAN requires compiling XS modules yourself. Usually not a problem, but it might not work out of the box. Also, you might have servers that don't have developer tools installed (like a C compiler).
The package manager of your OS may check certain resources first, for instance whether you have enough disk space to install something.

[reply]


Perl Monk, Perl Meditation
	PerlMonks