Will Perl upgrade break older version on Linux?

Question

I upgrade perl from perl58 to perl588 on Suse Linux.It looks that even though the Config.pm exists for the older version the newer version installation breaks the older version.While the upgrade of Perl on other OSes like HP and AIX does not disturb the older version. For eg: The perl58 and perl588 versions are present in folder say "/usr/standard_perl" as follows:

/usr/standard_perl/perl58 (directory)
/usr/standard_perl/perl588 (directory)

and have symbolic links pointing to it.

Before and after upgrade the links are as follows:

Before:

perl58_link -> /usr/standard_perl/perl58

After:

perl5_link ->   /usr/standard_perl/perl588 
perl58_link ->  /usr/standard_perl/perl588
perl588_link -> /usr/standard_perl/perl588

Now when i try to run simple "./perl -V" command from /usr/standard_perl/perl58/bin the older version complains of Config.pm not found even though its very well present in its own tree structure.

Is it that in Linux, perl is following a hard coded path for @INC.This kind of behaviour is observed only on Linux.

I am worried for I cannot roll to production for there are scripts that have been running for older version and if this kind of behaviour exists I would need to know if its possible to fix or this is a known behaviour of Linux.

I am not sure could this be because now the older links after upgrade is been pointed to newer version and just linking is not sufficient and need to modify something more on LINUX?

Note: 1.The perl modules are seperately maintained for each version 2.I am not mixing any of the files with previous version. 3. We want all of the old perl scripts running in production servers not to break and use latest version instead for the mainatainence of Perl versions. 3a.Hence a need to tweak the links pointing to latest version instead of their own versions.

Observation: Only on Linux seeing this behaviour. One point worth noting is when i twek links of older version to latest version. the @INC automatically is updated for latest version INC and not in LINUX.

Am i missing something here?

Answer 1

I've never seen this problem on Linux. I leave the original perl in its location (/usr/bin/perl), and simply compile my own perl to install to /usr/local/bin (or whatever), and have never seen any breakage of the old version.

You don't say

• how you came to have a /usr/standard_perl/perl588 (compiled, given in rpm format or something, pre-compiled tarball, ...)
• what options you used when configuring the compilation

You're also very vague with your details - perl58_link, standard_perl, etc. - where is this really? Most of the time it doesn't matter, but sometimes it does.

If you move the link back, do things start to work? If you move the entire 5.8.8 tree somewhere else, do things start to work? Can you recover your base perl from RPM or whatever to try to make it work? IMO, the base perl working is paramount, a secondary perl is always bonus. (I'd take the same opinion of other core unix tools, like shells, awk, sed, or even python or whatever your distro uses for package management. Less so for non-core tools like Java, but if I were running Java apps in production then I'd say the same here, too.)

Answer 2

Leave the system perl executable alone, compile your own, and have your Perl programs run using the one you compiled

All system programs written in Perl should start with:

#! /usr/bin/perl

All non-system Perl programs, user written programs:

This one will use which ever perl executable is found first on $PATH. (same as 'which perl')

#! /usr/bin/env perl

Another option is to specify exactly where the executable you want to use is:

#! /opt/bin/perl

#! /opt/perl/bin/perl

#! /opt/perl/5.10.0/bin/perl

#! /opt/perl-5.10.0/bin/perl

#! /home/$user/perl/bin/perl

#! ~/bin/perl

Or what ever the path to the perl executable is.

Answer 3

Never replace /usr/bin/perl with one you compiled yourself!

I did this once on Ubuntu 7.10, and it broke my system. I could login, and do most everything, but I couldn't change the appearance, for example. I ended up running 'sudo nano $filename' on every Perl program on my computer, and change them so they would run under Perl 5.10, instead of Perl 5.8.

After which I had to install Ubuntu 8.10 from scratch, when it finally came out.

You could also experience incompatibilities if you use cpan or cpanp to install modules, because they could have an incompatible feature change. And for a non-binary compatible perl executable, you have to reinstall all modules that require XSubs.

Thats why all Perl programs that I write I add the header '#!/usr/bin/env perl', and add the path to the Perl executable, to the beginning of the $PATH variable.