[sf-perl] upgrade hell?
bryan at beeley.org
Wed Oct 31 09:55:32 PDT 2012
While I haven't run into this particular situation myself, I would think
that you might save yourself some headache if you remove that "use lib"
line from your code. It would probably be easier to, at some later
date, put a symlink in place of the /user/local/lib/perl directory that
points to your (at that point newly upgraded) /nas/reg/lib/perl
directory, rather than have to hard code all your scripts.
Alternatively, you could set the PERL5LIB environment variable in the
user that is running your scripts. To give you an idea of my dislike of
hard coding paths in scripts, I tend to run scripts using the perl
executable of my choice rather than relying on the shebang line of the
script to point to the correct perl (or using env to pull it out of the
I think the closest migration I was involved in was migrating production
systems from a custom perl build on old VMs to fresh VMs with newer
versions of the OS we were using. For that setup we built and installed
perl the way we wanted it on one new VM instance, then used rsync to
copy our custom built perl executable and libraries to all the new VMs
(all the new VMs were the same and were running on the same type of
hardware). That way we had two sets of VMs both with complete copies of
all the perl executables and libraries we needed.
I'm not sure if any of this helps you with your situation.
On 10/31/2012 08:49 AM, David Alban wrote:
> thanks bryan,
> as you surmised, our cpan and home grown modules are installed in
> /nas/reg/lib/perl (symlink to /nas/reg/lib/perl5). /nas/reg/ is a
> network filesystem mounted by all of our hosts.
> we include the statement:
> use lib '/nas/reg/lib/perl';
> in all of our tools. i'm not sure what to do in the case that's fast
> coming up: the current hosts will continue running 5.8.8 but all of
> the new hosts will be running 5.10.1. perhaps we do use a /nas/reg2/
> filesystem, complete with its own /nas/reg2/lib/perl (symlink to
> /nas/reg2/lib/perl5) and reinstall all cpan modules there for 5.10.1.
> and perhaps we change:
> use lib '/nas/reg/lib/perl';
> in all of our tools to:
> usr lib '/usr/local/lib/perl';
> and on the 5.8.8 hosts /usr/local/lib/perl is a symlink to
> /nas/reg/lib/perl and on the 5.10.1 hosts /usr/local/lib/perl is a
> symlink to /nas/reg2/lib/perl ?
> again, looking for perspectives from folks who've gone down this path
> and have had to maintain two versions of cpan modules and home grown
> tools which use them.
> On Tue, Oct 30, 2012 at 7:02 PM, Bryan Beeley <bryan at beeley.org> wrote:
>> I have faced something like this several times. I have always installed
>> new versions of of CPAN modules without trouble, or having to muck with
>> with any of the defaults for library paths.
>> However, if you have your libraries in a custom location, it might be
>> worth creating a new directory for the new modules, or moving the old
>> directory(ies?) aside, before you reinstall everything from CPAN (maybe
>> install the new modules in /nas/reg2). I have always done this on
>> machines that have a default OS package install along with a custom
>> built Perl executable (usually built from source and installed in
>> /usr/local). I would expect that using the default system Perl with a
>> custom directory for core libraries is more likely to cause trouble when
>> mixing versions.
More information about the SanFrancisco-pm