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.

To add to your excellent points
• 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.
I'm not suggesting one should use CPAN or that one should use the package manager of your OS. I'm not consistent either - on some boxes I use CPAN. On others, I use the package manager of the OS. And on some boxes, I use the package manager of the OS, RPMs (which isn't the native package manager of that OS), and install CPAN modules manually.

My reasons some of which have already been mentioned.

1) CPAN will be aware of modules installed by YAST but not visa-versa. ie YAST will update the Perl module list but CPAN not the YAST install list.

2) More modules in CPAN, probably later versions (see what CPAN wants to update).

3) Maybe even get a better module to do the same task.

4) More control if you build it yourself. Get the options you want.

5)What if YAST update decided to update a module that then broke your proggy?

6)It's more fun to get and build with CPAN/CPANPLUS, especially when it doesn't always work and you have to delve to sort it out. You can learn a lot that way.

wow, this list is alive and well. Thank you for the responses!!! Another related question, if I choose to use yast, is there a url I can add to my installation sources to get the latest and greatest (and even additional) perl mods from cpan? Thanks!

No, 'YaST' and CPAN are not in sync. You will probably be stuck with the Perl modules that were packaged at the time the distribution release was made unless you install from CPAN. Personally I freely upgrade any of the perl module packages that came with the OS distribution, but there again I also have several other perl builds on the machine.

/J\

If the module I need either isn't packaged by the distro, or if I want a newer version, I install via cpan, but as my own non-privileged userid.

When you run CPAN as yourself, the questions tell you how to provide additional args to 'perl Makefile.PL' (PREFIX=foo) or 'Build.PL' (--install_base foo) to install in your home directory. I tend to put things in $HOME/install/perl.

Then you tell your shell to tell perl (when run as you) to find these modules:

export PERL5LIB = $PERL5LIB:$HOME/install/perl/share/perl
export PERL5LIB = $PERL5LIB:$HOME/install/perl/lib/perl
[download]

This also works nicely in the multiple-machine one-NFS-homedir setup.

wow, you guys are fast. jbert, these are for the webserver, so, in that case what would you do?

Hmmm....probably as described. Using the distro packages as far as possible helps keep you up to date on security fixes etc (as long as you are running your update commands).

If you *do* need something not packaged by your distro, set up a localised install tree as described above. I'd probably create a user 'cpan' to own it and install the modules to its homedir. If I was very paranoid, I'd actually install to /home/cpan/install/perl, check everything worked and then copy (rsync) the ~/install/perl to wherever I had configured the web server to pick them up from (somewhere not under your document root, obviously).

Note: you generally don't set environment variables for CGIs etc in .bash_profile for your web server user, but how you do it is web-server specific. The apache docs cover setting env vars pretty well.

Have fun and good luck.

That said, I'd go with the OS package management system for whatever modules it has. You will avoid any annoying CPAN dependencies and know for sure that it will just work for your system.

As mentioned in other comments, doing this you are kinda at the mercy of the folks who develop the packages to get them out quickly after a new version comes out on CPAN. However, unless you need the newest version or something weird, the benefits usually out weigh the problems.

Hello. Hi. I'm very new here, I hope this is the right place. I'm running SUSE10.1, and I notice that there are a bunch of perl mods listed under yast. Are these some of the same modules that I can install via CPAN? Will Yast see what CPAN installs and vice versa?

This is a kind of question that comes out quite often, either in the context of some distro community, or in a Perl-related one, with an overall preference for the particular distro's package tools in the former case and for CPAN in the latter, not surprisingly. Indeed, there are advantages to both approaches, as has been discussed here too. Now it seems to me that nobody has mentioned CPANPLUS yet, which supports creation of packages of one's choice through the cpan2dist tool: not all distros are targeted yet, but many "major" ones are, and it shouldn't be too difficult to add others, although I've not really investigated it yet. This makes for great news, since to some extent it "saves the best from both worlds!"