Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

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

by Perm (Initiate)
on Mar 14, 2012 at 18:28 UTC ( #959647=perlquestion: print w/ replies, xml ) Need Help??
Perm has asked for the wisdom of the Perl Monks concerning the following question:

In retrospect, it is not surprising the that 'yum update perl\*' replaced modules we upgraded or installed in /usr/lib/perl5/5.8.8. I would like to be able to patch without changing the modules our developers use.

Is installing modules in site_perl by setting installdir=site sufficient protection or are there module elements that will still be clobbered by Red Hat? Using site_perl keeps the modules in the default @INC path.

    I am testing installing modules we use in /usr/lib/perl5/site_perl/5.8 +.8 and leaving everything in /usr/lib/perl5/5.8.8 unchanged. This tes +t looks good to me. cpan> get PHRED/Apache-DBI-1.10.tar.gz [...] cpan> make PHRED/Apache-DBI-1.10.tar.gz [...] cpan> test PHRED/Apache-DBI-1.10.tar.gz [...] cpan> install PHRED/Apache-DBI-1.10.tar.gz [...] Installing /usr/lib/perl5/site_perl/5.8.8/Apache/AuthDBI.pm Installing /usr/lib/perl5/site_perl/5.8.8/Apache/DBI.pm Installing /usr/share/man/man3/Apache::DBI.3pm Installing /usr/share/man/man3/Apache::AuthDBI.3pm Appending installation info to /usr/lib64/perl5/5.8.8/x86_64-linux-thr +ead-multi/perllocal.pod PHRED/Apache-DBI-1.10.tar.gz /usr/bin/make install INSTALLDIRS=site -- OK

Is there an automated way to get the source files of the installed modules?

    I need to preserve the module version so I don't confound development debugging with module changes. The only way I know to maintain the version is to get/make/test/install the source file for the currently installed version. Install autobundle updates the module.

    cpan> get PHRED/Apache-DBI-1.10.tar.gz

Cpan shell settings.

    o conf make_install_arg INSTALLDIRS=site o conf mbuild_install_arg --installdirs=site o conf commit

Developers' Requirements

    Perl patches do not break the perl modules we use.
    The modules versions do not change while fixing the problem, e.g., ins +talling them in site_perl.
    We are running the same version of perl, 5.8.8, after the fix.
    No perl applications need to be modified, i.e., everything can be foun +d in the default paths.
    No changes to the programming environment are required.
Environment RHEL 5.6-5.8. Linux 2.6.18-308.el5 x86_64 x86_64 x86_64 GNU/Linux perl, v5.8.8 built for x86_64-linux-thread-multi
root# yum list installed perl\* Loaded plugins: downloadonly, rhnplugin, security, verify Installed Packages perl.x86_64 4:5.8.8-32.el5_5.2 perl-BSD-Resource.x86_64 1.28-1.fc6.1 perl-Compress-Zlib.x86_64 1.42-1.fc6 perl-Convert-ASN1.noarch 0.20-1.1 perl-DBD-MySQL.x86_64 3.0007-2.el5 perl-DBI.x86_64 1.52-2.el5 perl-HTML-Parser.x86_64 3.55-1.fc6 perl-HTML-Tagset.noarch 3.10-2.1.1 perl-IO-Socket-SSL.noarch 1.01-1.fc6 perl-LDAP.noarch 1:0.33-3.fc6 perl-Net-SSLeay.x86_64 1.30-4.fc6 perl-SGMLSpm.noarch 1.03ii-16.2.1 perl-String-CRC32.x86_64 1.4-2.fc6 perl-TermReadKey.x86_64 2.30-4.el5 perl-URI.noarch 1.35-3 perl-XML-NamespaceSupport.noarch 1.09-1.2.1 perl-XML-Parser.x86_64 2.34-6.1.2.2.1 perl-XML-SAX.noarch 0.14-8 perl-libwww-perl.noarch 5.805-1.1.1 perl-libxml-perl.noarch 0.08-1.2.1

Comment on How do I keep Red Hat perl RPM updates from damaging our local module upgrades and installations?
Select or Download Code
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
    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).)

      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.

      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 .

Re: How do I keep Red Hat perl RPM updates from damaging our local module upgrades and installations?
by Anonymous Monk on Mar 14, 2012 at 19:13 UTC
    Given how easy it is to roll up your own version of perl, I generally behave as if the OS installed version isn't even there & create as many alternate versions as suit us in /usr/local/.

    Remember, your OS vendor is only supporting perl to run it's own scripts. If it happens to also work for you, great.

    TJD

Re: How do I keep Red Hat perl RPM updates from damaging our local module upgrades and installations?
by trwww (Priest) on Mar 15, 2012 at 06:39 UTC

    Like the AM mentioned above, pretend like the system perl doesn't even exist. Its really (and I mean really) easy to make your own perl. You can even make a bunch of them (different versions, whatever you want).

    The easiest way is to use something like App::perlbrew. You'll install this module with the system CPAN, and then you can install and switch between perl versions with a couple simple commands.

    If you want to manage the installs yourself so you see whats going on, to me in many ways its even easier than perlbrew:

    $ wget http://www.cpan.org/src/5.0/perl-5.8.1.tar.gz $ tar -zxf perl-5.8.1.tar.gz $ cd perl-5.8.1 $ sh Configure -de -Dprefix=/opt/perl-5.8.1 $ make $ make install $ export PATH="/opt/perl-5.8.1/bin:$PATH"

    Now you have a throwaway perl in /opt/perl-5.8.1. Say you want to upgrade your modules but roll back if it doesn't work out. With this setup you can archive /opt/perl-5.8.1, do your module upgrades and test, and if it doesn't work out just delete /opt/perl-5.8.1 and extract the archive.

    See my reply at Re: Windows type needs to set up Linux with Perl 5.8.1 to match PAUSE for more summary and Re: 2nd Perl installation on Mac OSX for complete details of how I manage perl installations if you're interested.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://959647]
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (19)
As of 2014-07-11 17:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (232 votes), past polls