Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: How do I keep Red Hat perl RPM updates from damaging our local module upgrades and installations?

by Eliya (Vicar)
on Mar 14, 2012 at 19:09 UTC ( #959652=note: print w/ replies, xml ) Need Help??


in reply to How do I keep Red Hat perl RPM updates from damaging our local module upgrades and installations?

Is installing modules in site_perl by setting installdir=site sufficient protection

Using site_perl should be ok (though I'm not entirely sure how exactly Red Hat is packaging their stuff), but as site_perl would typically be later in the default @INC, you'd have to change that temporarily in order for your own module versions to be found (in your development environment) in case there are competing versions.

Anyhow, the common advice is to stay away from the system Perl entirely, and install your own Perl in some other directory (e.g. /usr/local/...). That way, you can mess with it any way you like without impeding the system Perl or being impeded by system upgrades.  (When you build your own perl on that box, make sure to configure it to not include existing lib directories (of the system Perl) into the default @INC of the newly built perl (as is the configure default).)


Comment on Re: How do I keep Red Hat perl RPM updates from damaging our local module upgrades and installations?
Select or Download Code
Re^2: How do I keep Red Hat perl RPM updates from damaging our local module upgrades and installations?
by chrestomanci (Priest) on Mar 15, 2012 at 10:41 UTC
    Anyhow, the common advice is to stay away from the system Perl entirely, and install your own Perl in some other directory (e.g. /usr/local/...). That way, you can mess with it any way you like without impeding the system Perl or being impeded by system upgrades. (When you build your own perl on that box, make sure to configure it to not include existing lib directories (of the system Perl) into the default @INC of the newly built perl (as is the configure default).)

    This is good advice, but not always easy to follow, because if you build your own perl, and then add the extra perl modules you need from CPAN, then it takes a long time, and you can sometimes hit dependency hell. This is especially problematic if you install something bleeding edge with lots of dependencies such as Catalyst

    On the other hand, if you rely on the distro version of perl, and install pre-built CPAN modules from the distro's archives, then the install is quick, and the perl packagers from the linux distro have already sorted out and fixed dependency issues.

    I am currently working on a Catalyst and Mason project using the latest version of Ubuntu as the server. I have found that I can install most of the the required libraries from the Ubuntu repositories. Where there are required libraries that are not packaged for Ubuntu, I have installed them using cpanminus, and it has worked nicely without conflicts or files getting clobbered.

    I realise that this solution is practical because I am using a recent Distro where the version of perl and the perl modules are recent and reasonably complete. This would probably not be a practical proposition if I where using an infrequently updated "Long term stability" distro such as Red Hat, Debian Stable or Ubuntu LTS.

    There may also be issues with the way Red Hat have packed their optional perl modules. Perhaps they are installing them in the same place as the CPAN tool does for locally built modules.

Re^2: How do I keep Red Hat perl RPM updates from damaging our local module upgrades and installations?
by Perm (Initiate) on Mar 15, 2012 at 14:36 UTC

    We are stuck with the Red Hat RPM for now and the foreseeable future. Installing our own perl is considered to disruptive.

    Site_perl is first in @INC. When I access the CGI.pm element of the @INC hash in my test below it returns the /usr/lib/perl5/site_perl path and not the /usr/lib/perl5/5.8.8 path which also has CGI.pm.

    CGI.pm exists in two locations. # ls /usr/lib/perl5/5.8.8/CGI.pm /usr/lib/perl5/site_perl/5.8.8/CGI. +pm /usr/lib/perl5/5.8.8/CGI.pm /usr/lib/perl5/site_perl/5.8.8/CGI.pm Which CGI.pm are we using? # perl -MCGI -le 'print $INC{"CGI.pm"}' /usr/lib/perl5/site_perl/5.8.8/CGI.pm # perl -V | tail -10 @INC: /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 .

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://959652]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (6)
As of 2014-09-20 11:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (158 votes), past polls