As Corion points out, don't mess with your production server right away. Bad Things® can happen if you do if there's an application out there that you don't know about that uses the Perl version that is out there already and if there are custom modules that have been loaded either from the vendor or CPAN.
So before you start pushing bits around, do some homework. Talk to your application support people and quantify the problem set before you go any further. Find out if and for what are they using the Perl sever for in their production environment. Your application support folks might not be Perl savvy enough to know what modules are being used or where they came from so be prepared to look at that stuff and figure it out for them. Make a list. Check it twice. You want to be nice not naughty! (Sorry.. couldn't resist...)
Once you have quantified what you are up against, then you want to do some more homework. If the applications and scripts in question come from an outside vendor then you have to take another step. Talk to the vendor and find out what you can from them. I'll warn you though, I've dealt with a couple of vendors that shipped Perl scripts with their end product that another party wrote (probably a contractor) and that party is not around to ask questions of. The company's own support staff definitely did not have their clue bit set with respect to the inner workings of the script. ("The script stopped working... what did you do to change it?" -- typical vendor)
If you are luckier that I was and somone at the software vendor has their clue bit set with respect to the scripts then you can find out things like "Oh... our module Foo::Frag::Fuzz is actually not compatible with version 5.x of Perl but is compatible with 5.y" or better yet "Oh.. if you are going to upgrade the Perl interpreter then you need to update our modules to version Z." (I've had that happen exactly once.)
Once you are armed with all that information, then you want to do your upgrades on a development, test or QA system and test the living daylights out of what you've done. Keep good records of what you are doing so problems that may come up are easier to trace.
Now, I've gotten way off my original track, but as far as SUN's cc or gcc goes the official answer is "It depends!" All but one of the companies I've worked at in the last 25 or so years has shied away from buying Sun's native compiler. (Actually at one time Sun's cc came with the OS "free" but that was a long time ago) If that's the environment you are in and you are stuck with "free" software to get your job done that limits your options. You can either compile from source or go visit sunfreeware.com and get the binaries from there.
Just a side note. I've had a much easier time compiling from source on Solaris 8 and 9 than I've had on Solaris 10. But that's for another discussion.
Once you've done your testing with the new Perl then you should work with your application support folks and figure out a plan for deployment. In my environment we have all our production servers "mirrored" in that there are at least two production severs for each functionality. So when we deploy something new out to production that can have a wide impact we deploy it to one server, wait a couple of days to let it soak in, and then to the other (or rest of the) server(s).
In reply to Re: perl update on solaris 8
by blue_cowdawg
in thread perl update on solaris 8
by rayzit
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |