How to deal with distro Perl modules _and_ CPAN ?

[Krambambuli]

Dear PerlMonks,

I wonder what the best [well, recommended, proven to be good ] practices are to deal with distro Perl modules _and_ CPAN modules.

My current approach - I'm currently on Fedora 10, but the question is actually the same for all Linux distros - is to use the distro's install/update mechanism, then install/update CPAN and update/upgrade everything that's newer on CPAN.

With some rare exceptions, this seems to work pretty well - the only annoyance is that whenever the distro stock Perl is updated, I have to repeat the CPAN-syncing procedure, as some (lots...) of the previously updated modules seem to get lost during the Perl upgrade.

I can live with that, however I wonder how other Monks are dealing with this problem. Never installing the distro stock Perl and associated modules seems a bit too harsh to me.

Many thanks in advance,

[ELISHEVA]

What is the best way to install CPAN modules on Debian? discusses some of the options for Debian. Debian uses its Perl distro as part of its OS - compunding the problem. There are also some scattered comments about Solaris, Ubuntu, RedHat, CentOS, among others (no Fedora though). Perhaps you would find it helpful.

Best, beth

[mikeraz]

Double Plus Plus endorsement of Beth's suggestion. The original question is written excellently and followup discussion packed with thoughtful suggestions.

[Bloodnok]

I'm now using Ubuntu i.e. no Windoze, for any perl development and found your base strategy to work reasonably well ... until I came to install Devel::ptkdb.

What fun and games I had trying to first identify, then locate and finally install Tk and all the dependencies on my laptop.

When I came to install on the desktop, I discovered the perl-tk package - which, as does as it says on the tin, and delivers it [Tk] at the press of a button - what luxury - thus considerably simplifying the CPAN installation of Devel::ptkdb.

The conclusion is, like a lot of things, to abide by the spirit of the KISS acronym - if it's already been made easier (by being pre-built & packaged) then use it (someone else has already been thro' the pain & it would be rude to ignore their effort - .oO(If only there were ways to recognise it)), otherwise use the CPAN approach.

Just my 2 pen'orth

[przemo]

My current approach - I'm currently on Fedora 10, but the question is actually the same for all Linux distros - is to use the distro's install/update mechanism, then install/update CPAN and update/upgrade everything that's newer on CPAN.

I've never tried that although I was very tempted.

An interesting point was made by chromatic on Modern Perl Books blog:

OS vendors who package and distribute Perl and use it for core utilities should install their core libraries in a specific directory accessible only by their core utilities and they should configure Perl to install modules from the CPAN in another directory where their utilities do not look.

That is, if you distribute Perl as part of an OS or distribution, and you distribute Perl utilities which the system needs to function, you must pay attention to specific library versions and ensure that the proper library versions are available, even if users install newer versions from the CPAN.

Do OS vendors do so? Unless I don't understand above quote, keeping /usr/local at the beginning of @INC for e.g. scripts in /usr/sbin is "broken-CPAN-update-prone".

$ sudo perl -V
  @INC:
    /etc/perl
    /usr/local/lib/perl/5.10.0
    /usr/local/share/perl/5.10.0
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.10
    /usr/share/perl/5.10
    /usr/local/lib/site_perl
    .