|
twieckow has asked for the wisdom of the Perl Monks concerning the following question:
Hello, I have an issue, where perl runtime 5.8.8 runs on AIX 6.1 . This is the default version that comes with AIX OS. I then go to upgrade my OS, of which IBM includes an upgrade of perl runtime (perl.rte) this upgrade will overlay/backlevel modules of which I installed specifically for user request. Case in point, I installed Spreadsheet::XLSX that needed FILE::TEMP v. 0.2304.
When I went to upgrade my OS, the Perl bundle "backleveled" the Temp.pm file which got installed from v.2304 of File::TEMP, thus the users program bombed. This was file /usr/opt/perl5/lib/5.8.8/File/Temp.pm, Until I was able to re-install the module. Now, I go to IBM with this issue, indicating that their upgrade process is bombing my "installed" modules for specific programs. They (IBM) indicates that they do not support Perl and that they just get the bundle for their latest upgrade from perl.org. I am at a loss on how to proactively prevent this "backleveling" of modules and or to Identify those that are getting installed with this new runtime release.
I hope this makes sense, and appreciate the help in advance. Thank you. |
Re: Upgrading perl under AIX issues.
by jeffa (Bishop) on Jul 21, 2015 at 18:40 UTC
|
This one of the few reasons i highly recommend that you install and use perlbrew instead of the system perl. You install the perl(s) you want, into your local dir without the need for privileges. You install whatever CPAN modules you want via cpanm and then you ensure that your scripts use that perl and not the system perl by either changing the shebang lines or setting up symlinks. It is very much worth the time and effort.
jeffa
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
| [reply] |
Re: Upgrading perl under AIX issues.
by MidLifeXis (Monsignor) on Jul 21, 2015 at 18:51 UTC
|
Do not use the system perl for your scripts if you need anything not on the base system, and even then, it is a risk. System perl is for the system, not your software.
Install your own. You decouple yourself from the OS's perl version, ensuring that you don't break the system perl with any upgrades, or that system updates don't break your software.
| [reply] |
|
|
| [reply] |
|
|
It depends on how you view the OS. Here, I view it as a platform to place my application stack over. IT has responsibility for the OS, I have responsibility for the application. Since the goals and needs of IT at the OS level and my team at the application level are similar, but never identical, I have found that including the runtime environment within my application installation provides a much more stable and reliable application for my users. If the OS de jour changes (as it may), it also gives us (assuming proper isolation of the OS touch points) the ability to migrate while minimizing porting effort (a lesson learned the hard way).
Add into that vendors for part of my application environment that require a specific version of Perl (binary library distribution), and I actually have multiple versions of perl in my application stack. One for each vendor's required version, and one for my overarching application. The parts communicate along well-defined lines of demarcation, allowing for a smoother update process for each component. An additional benefit along for the ride is also being able to move part of the environment to another machine and basically being able to change the location of the resource.
It took me many years and may head/heartaches to settle on this configuration, but it seems to work quite well.
| [reply] |
Re: Upgrading perl under AIX issues.
by codiac (Beadle) on Jul 22, 2015 at 09:53 UTC
|
Perl has 3 paths it checks for modules, site, vendor, & perl. Vendor supplied modules should go in perl or vendor, because the default is site which is where modules you install should go.
You can run this to get the 3 paths printed out in the order above perl -e 'use Data::Dumper; print Dumper(@INC);'
If the core modules are going in to site then the package being supplied by IBM has an install bug and they should fix it. If they are installing in to the right places but modules you install are going to vendor or perl, then you need to force them to install to site. See: http://perldoc.perl.org/ExtUtils/MakeMaker.html#INSTALLDIRS
| [reply]
[d/l] |
Re: Upgrading perl under AIX issues.
by Tux (Canon) on Aug 24, 2015 at 14:07 UTC
|
Forgive me in sounding a bit rancorous, but in my 20+ years of using AIX, I have never been able to spot recent or even up-to-date OpenSource software readily available for AIX.
On systems that - by their standard - come with that ancient versions of software you use on a daily basis, the first thing to do is take control: find yourself the best version of perl to match your project. That version should show a PASS on CPANTESTERS (currently down, but I hope back up very soon) for all the modules you plan to use.
Then install that version as your production version in a location that does not conflict with system perl. /yourcomapy/perl might work very well.
Then amend your $PATH to make that perl your default perl and install all the additional modules you need with cpan or cpanm. As of now you have no more dependencies on whatever (stupid) change IBM thinks useful for system-perl.
One final advice here though, which triggered me to reply at all: do NOT use Spreadsheet::XLSX. It is dead, unmaintained, buggy and deprecated. Please take the time to make the switch to Spreadsheet::ParseXLSX.
Enjoy, Have FUN! H.Merijn
| [reply]
[d/l]
[select] |
|
|
Thanks Tux! for the input. Points taken.
Best regards,
| [reply] |
Re: Upgrading perl under AIX issues.
by twieckow (Novice) on Aug 24, 2015 at 13:22 UTC
|
Thank you all for your input. Hindsight being 20/20 yes, should have never placed application perl scripts accessing system perl. I am now looking for "best" way to "decouple these 2 from each other. Did not know of perlbrew before. I will look to see how I can implement this. These are production systems using perl, and have to tread lightly.
If anyone has any steps/recommendations on achieving this, it would be highly appreciative.
Regards | [reply] |
Re: Upgrading perl under AIX issues.
by twieckow (Novice) on Aug 26, 2015 at 12:42 UTC
|
Folks, After having read the comments and researched perlbrew further, I would like to see if I can get some further advise on how to decouple my application perl from the system. I would like to make a mirror image of the existing system perl environment so that my application programmers can run from there. I copied the environment to another area on my test box, but I believe that there is more involved in order to have this perl environment segregated from the other (namely changing @INC, PERL5LIB) etc.) I can then add modules as requested from the appl. programmers, and for the most part not effect the the system perl. Would appreciate it if anyone would have steps involved , so that I don't miss anything. Thanks very much in advance for the help.
BTW, I can use perlbrew in the future , once this decoupling as happened.
regards,
Tom | [reply] |
| A reply falls below the community's threshold of quality. You may see it by logging in. |
|
|
