Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

This may not be the correct place to pose my questions, but it is the best place I have found. If there is a better place, please advise me where.

As a sysadmin, I have a burning question about PERL.

I am trying to understand why every upgrade of PERL installs a completely new directory tree under /usr/lib/perl5 and usr/lib/perl5/site_perl? I can definitely understand it for a major release, and partially for each minor release, but for every point release seams like major overkill.

Part of my problem with this is disk space, but that is minor compared with the fact that it then requires re-installing every CPAN module or third party add0on that we use. This would not even be quite as big a problem except that 1) it means that some of our applications are down until we can get every module re-installed, and 2) It is very difficult to keep track of every module that is installed so we can make sure that we get them all re-installed.

If CPAN had a function similar to PEAR that wwill tell us what modules are installed, and even do semi-automatic updates, it would aleviate at least a substantial amount of the pain.

Any insights or suggestions will be greatly appreciated.

20050124 Edit by castaway: Changed title from 'Sysadmin seeking wisdom'

  • Comment on Sysadmin questions on efficient installation of new Perl versions

Replies are listed 'Best First'.
Re: Sysadmin questions on efficient installation of new Perl versions
by mpeters (Chaplain) on Jan 21, 2005 at 17:43 UTC
    It might make your life a lot easier if you create a Bundle of the CPAN modules that you have installed. This would not only help during an upgrade but you could use the same bundle on different machines to make sure that they are in sync.
[reply]
      Thank you.

      Simply using autobundle before updating perl will save much worry and pain even though it still doesn't solve the downtime for an update.

[reply]
        Where is the downtime coming from? Can't you install a new version of Perl, get all the modules installed and everything tested, then change /usr/bin/perl to point to the new version?
[reply]
Re: Sysadmin questions on efficient installation of new Perl versions
by Solo (Deacon) on Jan 21, 2005 at 18:04 UTC
    From the CPAN POD:

    perl -MCPAN -e 'CPAN::Shell->install(CPAN::Shell->r)'

    [download]

    --Solo

    --
    You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
[reply]
[d/l]
Re: Sysadmin questions on efficient installation of new Perl versions
by bluto (Curate) on Jan 22, 2005 at 00:02 UTC
    This would not even be quite as big a problem except that 1) it means that some of our applications are down until we can get every module re-installed, and 2) It is very difficult to keep track of every module that is installed so we can make sure that we get them all re-installed.

    For (1) I tend to build perl in it's own tree, install modules I need, and then symlink to it. That way the down time is almost zero when upgrading to a new version (just move the symlink), and if you run into a problem during the build it's no big deal. Also, it's easy to move Perl to machines that have a similar architecture and OS version, which is hard to do if it is installed somewhere like /usr/local where everything is mixed together.

    For (2) I punt. I can't use CPAN or CPANPLUS, for various reasons, and so I tend to keep the original source dirs for these around as well and rebuild them -- not much fun.

[reply]
Re: Sysadmin questions on efficient installation of new Perl versions
by BrowserUk (Patriarch) on Jan 21, 2005 at 18:12 UTC

    Beware of CPAN.PM. It'll take over your machine and screw it into the ground.

    Investigate CPANPLUS

    Examine what is said, not who speaks.
    Silence betokens consent.
    Love the truth but pardon error.
[reply]
[d/l]
Re: Sysadmin questions on efficient installation of new Perl versions
by AJRod (Scribe) on Jan 21, 2005 at 22:56 UTC
    Have you weighed if the benefits of upgrading to a minor revision of Perl far outweigh the annoying work disruptions you mentioned? I am sure you have but I am asking for the benefit also of other readers. I mean, I have encountered several systems that have been running for years on versions between 5.0 and 5.2, probably avoiding the same problems you've had or whatever hassles. As far as I know, they haven't had security related problems yet so far... Just a thought.
[reply]
Re: Sysadmin questions on efficient installation of new Perl versions
by castaway (Parson) on Jan 24, 2005 at 08:01 UTC
    It may create a new tree, but it does not require you to reinstall every module under that new tree. Look at the configure options (when building perl), you can tell it to also look in the directories of the previous installed versions. (Except for binary/compiled modules, these will need to be recompiled for the new version)

    C.

[reply]
Re: Sysadmin questions on efficient installation of new Perl versions
by renz (Scribe) on Jan 21, 2005 at 20:31 UTC
    Just out of curiosity..

    1) Since you list diskspace as an issue, why are you keeping every old revision of perl on disk? Is rm somehow broken?

    2) Why do you need perl to keep up with your addons and modules? Can't you just mv your lib directories? Is mv somehow broken too? Anyway, a bundle is a good idea.

    /renz.
    "I often wonder if I really need all of these bones." --Sean Stolon.
[reply]
      1) I don't keep them all, but I have had trepidation about removing them when I am not sure WHY perl creates a complete new directory structure for each update. If it is completely safe to remove them, then why is it not safe for the update to install into the same directory?

      2) You have it backwards. The problem is keeping all addons and modules installed when updating perl. Again, if it is safe to just mv everything, then why does perl install into a completely new directory structure?

[reply]
        1) Perl creates a new directory because not every version (or subversion) is binary compatible. This means that if you had installed any perl libs that used XS (C code) they would not be guaranteed to work with a different version of perl than the one they were compiled against. So Perl avoids these problems by creating a different directory so that multiple perls can exist on the same system.

        2) AFAIK it is not completely safe to just mv the directories. Only if you know that they are pure perl should you risk it. Even then you won't know that the old module passes it's test suite under your new version of Perl.
[reply]
        AFAIK, you only need one distribution of perl. I never keep old distros. I am not aware of the logic behind the directory structures for each new release, but I understand your distress.

        I don't think it is a matter of it being inherently unsafe to install to the same directory as much as it is that it prevents you from doing something really stupid, like maybe overwriting perl5 directory with perl4. Shrug. God only knows how that would accidentally happen, but in a short time on this planet I have seen a lot of crap that mathematically shouldn't have happened but did anyway.

        Anyway, I always move my modules, but I imagine that I have a significantly smaller number installed than you do, which is why making a bundle is such a good alternative to remembering each one installed. I don't see why it would be a problem.

        Anyone with a clearer explanation out there?

        /renz.
        "I often wonder if I really need all of these bones." --Sean Stolon.
[reply]

Back to Seekers of Perl Wisdom