in reply to How to install CPAN modules

Some Linux distributions distribute a very stripped down version of Perl, but still call the package "perl".

Your best bet is to locate the proper package that contains the full installation of Perl and install that throught the package manager of your distribution. Maybe for CentOS, you can install the CPAN.pm directly:

yum -y install perl-CPAN

Note that it is a highly unwise idea to use CPAN.pm with the package manager of your distribution. The Perl of your distribution should only be managed through the package manager of your distribution.

In the long run, it's best to install your own private Perl for your applications through perlbrew.

Replies are listed 'Best First'.
Re^2: How to install CPAN modules
by LanX (Saint) on Dec 27, 2013 at 07:59 UTC
    It could well be that CentOS excluded CPAN.pm on purpose too hamper such installations!

    Searching CentOs How to install CPAN modules¹ directly leads to a page stating

    If your system is one of the most popular Linux distributions then by far the easiest way to install additional CPAN modules is to use the package management system.

    For distributions like RedHat, CentOS, Fedora, Mandriva etc most CPAN libraries are available as RPM packages. If you need a CPAN library called CGI::Session then the naming convention normally used is perl-CGI-Session. ...

    IMHO changing system Perl (IF REALLY necessary) should always be done with a package manager, cause they are meant to allow clean and easy rollbacks. (dunno how far the guaranty goes)

    On all accounts your recommendation of perlbrew for an alternative private installation is surely preferable!

    Cheers Rolf

    ( addicted to the Perl Programming Language)

    ¹) which is just the threadtitle + OS, shouldn't be too difficult...

Re^2: How to install CPAN modules
by marinersk (Priest) on Dec 27, 2013 at 13:38 UTC

    Corion, the recommendation is surely solid, coming from the likes of you and seconded by the likes of LanX, but what I am gleaning from this is very disturbing.

    I have long wanted to get into Linux, but my hobby time has drifted away from those kinds of projects and my career work has been astoundingly Windows-based for several decades now. I must therefore confess an unusually deep case of ignorance regarding most things Linux. Please keep that in mind as you parse through my question and concern.

    It sounds to me like you are saying that I, were I a Linux sysadmin, notably on this version of CentOS, cannot establish a systemwide Perl installation for all users to use (including those coming in through a web site hosted on this server) which has any CPAN modules installed. I can only use the ones that are available on my Linux distribution.

    Rather, it appears you are recommending I set up a special Perl installation for each user on this system, or that they must set up their own. So if I have 100 users plus myself, I need to support 101 potentially varying installations of Perl.

    Please tell me I am misreading this.

      Please tell me I am misreading this

      You are misreading this.
      As a sysadmin, you would be able to install a "systemwide Perl installation for all users to use" - one that is separate and distinct from the perl that the system uses.

      Typically, it would be in some place like /usr/local, and users would *not* have permissions to install CPAN modules into this perl's @INC directories.
      But that would not prevent them from installing modules (to use with this systemwide perl) into their home directories.

      Cheers,
      Rob

        To be honest: i'm still unsure about this issue.

        For the moment, i prefer to have one or more functional users (like sybase or monitoring or whatever) and each one having a own Perl installation in his $HOME - managed with perlbrew.

        Regards, Karl

        «The Crux of the Biscuit is the Apostrophe»

        Got it. Thanks. I was lumping "system Perl" with "system-wide Perl" -- clearly a noob error.

        Much relieved am I.

      I am not a "real" sysadmin in the sense that I neither get paid nor do maintain a system that is used by more than a handful users. That said, my approach for maintaining a Perl installation would be to add a perl user group and install the "company Perl" under /opt/perl. All users in the perl user group can install or upgrade modules from CPAN with that custom Perl.

      Important reasons for me to keep a separate Perl installation are that the system Perl belongs to the system. Important decisions, like whether to build Perl with or without threads and/or to build mod_perl should not rely on the decisions for the system Perl, because the factors going into that decision for the "general use stock Perl" might well differ from the factors influencing my decision. Also, specific language features or the package repository used might influence my decision here.

      In general, I've come to the conclusion that for maximum stability, I want a separate Perl installation for every application, if not a separate virtual machine for every application. This of course makes maintaining the (security) upgrades a hassle. An interesting midpoint might be to use something like Carton to package up a specific set of modules and still use a common Perl binary.

      Using the stock Perl is always problematic in the long run for me, because it is highly likely that I want a module that is not (yet) packaged by the distribution maintainers. I could install the module into a local directory, but that means that I will still encounter breakage if the distributors decide to upgrade the stock Perl to a new version. Apple security updates to Perl for example tend to break manual (XS) module installations because they are not always binary compatible.

      > seconded by the likes of LanX,

      Disclaimer: I don't see myself as sysadmin and do not claim to be the authority here.

      It's just common sense: (and already said, but since you are addressing me...)

      The system installation of Perl is part of OS critical processes and can be changed by OS updates.

      OTOH applications like web-services have other requirements.

      In a one-user box like my laptop w/o critical processes conflicts may be rare and easily resolved, but in large scale installations (multi-server, -user, -responsibilities) you want to keep full control.

      Cheers Rolf

      ( addicted to the Perl Programming Language)