Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Solaris, Perl 5.8 and use 5.005

by ZlR (Chaplain)
on Mar 07, 2005 at 12:38 UTC ( #437185=perlquestion: print w/ replies, xml ) Need Help??
ZlR has asked for the wisdom of the Perl Monks concerning the following question:

Fellow monks,

I will soon have to argue at a meeting for the "pro" side of a migration from 5.005 to perl 5.8 , on a Solaris 6 server .

The "against migration" side have the following arguments :

  • You can't upgrade to 5.8 without an upgrade of the OS .
    I find this hard to believe.
    Can those of you who have done it before summarize (or give a reference document of) the install of perl 5.8 on a Solaris 6 platform ?
    Which of the available versions do you recommand and why ?

  • Company policy is to have only one version of the perl binary
    I think that this is uselessy downsizing the possibilities offered by Perl and Unix. But in fact this goes my way since "target" version is 5.8 .
    Speaking of that : does anyone know of a good document describing multiple perl installations with application or user specific private trees for libs and modules ?

  • Existing apps will break
    This is where i plan to propose to use 5.003 . I've never seen it used, and this here is production code .
    Does it 'just work' ?
    Does it impact performance ?
    Bonus question : how does the interpreter make it work , i mean, inside ?
    I'd like to say that this approach is "perl 6" compliant since having a use VERSION will also make it work with perl 6 : is that correct ?

    Thanks for your advice, i'll let you know if we win the case !

    zlr

  • Comment on Solaris, Perl 5.8 and use 5.005
    Re: Solaris, Perl 5.8 and use 5.005
    by Joost (Canon) on Mar 07, 2005 at 12:44 UTC

        Use 5.003 just specifies the minumum perl version, it does not alter the behaviour of the perl interpreter in perl 5.

        Ah okay, it was too good to be true :|

        I don't know about Solaris 2.6, but I know that installing over top of the factory-installed perl in Solaris 8 (might've been Solaris 7) caused problems. (what they were, I don't particularly remember, as it's been a couple of years, and I learned from it, and never did it again).

        So long as you install into /usr/local/bin, and do not replace the perl in /usr/bin, and do not set root's PATH with /usr/bin/local before /usr/bin, you'll be fine.

        Users can then specify /usr/local/bin/perl or /usr/bin/perl as they want in their shebang lines. You will have to install whatever modules you may need all over again, and you should not have them use the same include paths (unless possibly if you have locally maintained pure perl libraries that you don't want to maintain in two places, you might share those, but for everything from CPAN, I'd install all over again).

        I'm guessing though, if you're still running Solaris 2.6, you have other problems to worry about. (2GB file limit which could result in truncated backups, etc.) Depending on the exact situation, I might push the 'we need to upgrade', just to move off of Solaris 2.6, if that's what it would take to push the change.

    Re: Solaris, Perl 5.8 and use 5.005
    by cog (Parson) on Mar 07, 2005 at 13:22 UTC
      1) Why do they say that?

      2) I used to work at a company which had the policy of having documentation in Word format, while the development was being done in *nix platforms. Needless to say, their documentation was not as good as it should be... What I'm trying to say here is that just because something is company policy doesn't mean it's a good practice (but I'm not saying that only one single version of the perl binary is bad). Anyway, I can't see any problem with removing the older perl binary for the newer one; you shouldn't have any problem with that, but see the next point and do test the apps.

      3) Can't help you with your questions, but regarding "Existing apps will break", how about including a testing part in the migration process?

        1) Hmm, i think the perl was long ago compiled from source by someone who wasn't in the know. After that someone modified it in some strange ways, and it became a mess.

        Now noone knows what's going on with it and if they want to make it clean by company standard they need to upgrade to solaris 8 : that's because Solaris 6 is being discontinued here so if you need to change something with the OS team it will have to be solaris 8 .

        All this is mainly extrapollation from what i understand since it could also very well be political obfu or management war or whatever.

        Also the dev server and the prod server are in different OS version ... Well , it just ain't nice .

        I'll tell you more when i hear what they have to say 'Live' !

        2) I have a feeling no one is really in charge of this ... Well there is a team in charge of things like version shipements, but for some reasons they also/mainly do mainframe things ?! I think their "one binary only" solution will not really solve problems because i haven't (yet ?) heard of a module management strategy. If everyone installs their own modules where they want it's bound to go chaotic !

        3) As always it's a money thing. Also the code is quite old and seems awfull in some parts, so some ppl fear the results. On a "company scale" there's also a problem with the hudge number of servers and apps . For our own little app i guess we can go with two binary (if allowed), and/or a testing process ...

          I'll tell you more when i hear what they have to say 'Live' !

          Actually, this sounds a lot like a good beginning for a use Perl journal. Why don't you start one? (or post there, if you already have one) I'm pretty sure you'd also get a few responses there.

    Re: Solaris, Perl 5.8 and use 5.005
    by dragonchild (Archbishop) on Mar 07, 2005 at 13:55 UTC
      First, before you do anything, you have to justify why you want to upgrade. There are some reasons that are irrefutable. These are the "We want to use feature XYZ and it's only in version 5.x.x". Features like that would include:
      • Near-transparent handling of Unicode (5.8)
      • A threading model worth having (5.8)
      • Granular warnings (5.6)
      • A module from CPAN that only works on version 123

      Additionally, there have been hundreds of security and bug fixes since 5.005_00 was released, all of which are in 5.8.6 (the latest version thus far).

      A major reason --NOT-- to upgrade is that you have to reinstall EVERY SINGLE module, and all their dependencies, and all their dependencies, etc. The 5.8 series is not binary compatiable with pre-5.8 installs. This reason alone is sometimes justification enough to avoid an upgrade.

      Additionally, if it ain't broke, why you trying to fix it? It's not like 5.005 is unstable through aging or has gained cruft in the time since it was released ...

      Now, to answer your specific questions.

      1. You can't upgrade to 5.8 without an upgrade of the OS.

        This is flat wrong. I have run 5.8 on operating systems that were released before Perl5 was even a twinkling in Larry's eye. The easiest way to disprove it is to build your own personal copy of Perl. To do this, you download stable.tar.gz from http://www.cpan.org and use ./configure PREFIX=~ when you build it. The build will take roughly a workday and hammer the server, so I suggest you kick this off overnight after you've done the configure.

      2. Company policy is to have only one version of the perl binary

        Company policy is unchangeable, at least from the level it seems like you are. Multiple Perl installations are easy - just call them different things or put them in different places. They will install their libraries in directory structures that include their version number, so there's no clobbering.

      3. Existing apps will break

        Yes and no. You will have to reinstall the entire module base, but that won't break existing apps. Unless, of course, you install incompatible versions of certain modules, like Class::MethodMaker whose API changed between v1 and v2. Or, if you depended on a bug in a prior version of a module and that bug has gone away.

        The easiest way to test if this will happen is to install 5.8.6 in your home directory and try your applications with it. If they work, that will give management a bunch of warm fuzzies. If they break horribly, that allows you to not look stupid when the migration is approved and you can't make it happen. (That's because you were sick on the day of the meeting and shut your hole.)

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

        Hello dragonchild , and thanks for your answer .

        Additionally, if it ain't broke, why you trying to fix it?

        A new app will be developped on this server . We don't want to start developpement with 5.0 .

        You will have to reinstall the entire module base,

        Is it not possible to have a second perl binary, with a different she bang and a different default @INC ? If i manage to have two perl binary (you never know) then i also want to have two different module librairies. This way existing application does not have to migrate, new application is 5.8 .

        In the case they insist to have only one binary, i understant we should check code and tree for modules and reinstall them .
        This meeting is a first, no one's in charge of nothing, and i will certainly listen to what the conservatives have to say. But if it starts with "we need to re-install solaris", then i don't know .

          Yes it is entirely possible to have a different Perl installation - you simply use a different PREFIX when you run Configure. IMO this is preferable to replacing an existing perl if you don't want to have to test and possibly fix a whole bunch of existing code. And it is definitely what you want to do if you have a preinstalled Perl that came with your OS (though I don't think Solaris 6 did.)

          /J\

          I'm willing to go out on a limb and say unequivocally "You will never need to reinstall Solaris to install Perl 5.x.x". If they persist, ask them for their proof and bring it back to us. I feel very comfortable that we can provide answers that will satisfy.

          Being right, does not endow the right to be rude; politeness costs nothing.
          Being unknowing, is not the same as being stupid.
          Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
          Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

          As gellyfish said, you can have multiple perls installed simultaneously:

          $ perl -v This is perl, v5.8.0 built for i386-linux-thread-multi (with 1 registered patch, see perl -V for more detail) Copyright 1987-2002, Larry Wall Perl may be copied only under the terms of either the Artistic License + or the GNU General Public License, which may be found in the Perl 5 source ki +t. Complete documentation for Perl, including FAQ lists, should be found +on this system using `man perl' or `perldoc perl'. If you have access to + the Internet, point your browser at http://www.perl.com/, the Perl Home Pa +ge. $ perl5.8 -v This is perl, v5.8.6 built for i686-linux Copyright 1987-2004, Larry Wall Perl may be copied only under the terms of either the Artistic License + or the GNU General Public License, which may be found in the Perl 5 source ki +t. Complete documentation for Perl, including FAQ lists, should be found +on this system using `man perl' or `perldoc perl'. If you have access to + the Internet, point your browser at http://www.perl.com/, the Perl Home Pa +ge. $ p58 # change environment $ perl5.8.3 -v This is perl, v5.8.3 built for i686-linux Copyright 1987-2003, Larry Wall Perl may be copied only under the terms of either the Artistic License + or the GNU General Public License, which may be found in the Perl 5 source ki +t. Complete documentation for Perl, including FAQ lists, should be found +on this system using `man perl' or `perldoc perl'. If you have access to + the Internet, point your browser at http://www.perl.com/, the Perl Home Pa +ge.

          Note - I have 5.8.4 and 5.8.5 installed as well. Except for 5.8.0, they inherit each others' modules, as well. 5.8.0 is what comes with RHEL3, which I leave as-is so that RHEL3 apps continue to work, while the rest were compiled into a new directory, /share/perl5, and are what I use for my own code. Before I upgraded to RHEL3, I had RH7.3, which had Perl 5.6, and I also had compiled 5.8.0, and 5.8.1.

          As to "start developpement with 5.0" - that's not quite what you're doing. Between 5.005 and 5.6, Perl renamed its numbering scheme a bit. 5.005 in the old scheme is the same as 5.5 in the new scheme. Which is significantly newer than 5.0 ;-)

          Update: After re-reading the output, I realised that I hadn't updated my perl5.8 symlink to the latest perl version. Corrected the output above.

        I have the wonderful joy of having virtually the same issue at my company (using perl 5.005).
        First, before you do anything, you have to justify why you want to upgrade. There are some reasons that are irrefutable. These are the "We want to use feature XYZ and it's only in version 5.x.x". Features like that would include:
        • * Near-transparent handling of Unicode (5.8)
        • * A threading model worth having (5.8)
        • * Granular warnings (5.6)
        • * A module from CPAN that only works on version 123
        To this list you can add:
        • the ability to use warnings without -w
        • the ability to have our $var
        • better handling of FOO->method;
          (broken in 5.005, must type FOO->method(); )
        Since legacy code is mostly likely to break with such a new verison of perl, it is important to upgrade in a graceful way. The best way to do this is to install perl 5.8 in its own directory (your home dir perhaps, or /usr/local/bin), install all the CPAN modules you need, and migrate over one perl app at a time, testing as you go. Eventually, every app can point to perl 5.8 if the effort is made to port it, and those apps that are not ported to perl 5.8 can happily stay the way they are.

        -------------------------------------
        Nothing is too wonderful to be true
        -- Michael Faraday

    Re: Solaris, Perl 5.8 and use 5.005
    by Anonymous Monk on Mar 07, 2005 at 14:32 UTC
      My god man upgrade the OS! Is there some application you guys have in house that needs to run or 2.6 or something? You are missing out on tons of benefits by not at least being at Solaris 8.
        They're also missing out on the transition costs, which can be extremely substantial.

        There are programs written in the late 70's that are running on hardware built in the early 70's that have been touched only to make them Y2K compliant (and some not even then). These programs do everything from keep the lights on to issue Treasury bonds to determine whether a nuclear-tipped missile should launch or not. I don't know about you, but I'd rather not "upgrade" a nuclear-weapons computer when it's been working just fine for 30+ years. But, maybe I'm just paranoid. Maybe, you can keep track of every change made between version 3.4 and version 27.8 and calculate how each will affect every one of the million lines of code written in a language that was deprecated when I was still in diapers.

        And, maybe we just didn't need Detroit.

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

          Every time i hear this argument im reminded of something. For a while we had a system that nobody wanted to touch. It was a scary hack done by someone in the far reaches of time. Well one day somebody was bold enough to decide to write a replacement system. They put it into play and did a paralel run. Much consternation was caused by the fact the outputs were different. The developer of the new system however was pretty surprised by this and as such began to do a detailed analysis of the code involved. Turned out the output of the two systems was different because the original system never worked properly in the first place. Well, needless to say the old system was soon replaced by the new system, and lo and behold, much money was earned and much rejoicing was done.

          Not that it means your point is wrong, but there is another side to it. ;-)

          ---
          demerphq

    Re: Solaris, Perl 5.8 and use 5.005
    by JSchmitz (Canon) on Mar 07, 2005 at 20:30 UTC
      What hardware are you running on? Eventually its going to wear out and you are going to need to upgrade anyway. 2.6 is WAY deprecated. Anyways assuming you are not going to upgrade the OS you could check out Sun's Live Upgrade option where you can build an alternate boot sector while running, then mount that..install the new version of perl there - Boot from the sector during the outtage window and test your apps. If they blow up you can boot back from the old sector and blow away the other one. If this is a multi-domain system (E10K, 6800, F15K)you could also DR in a spare board and do your testing that way
      Cheers

      Jeffery
    Re: Solaris, Perl 5.8 and use 5.005 - PAR
    by Eyck (Priest) on Mar 08, 2005 at 07:52 UTC
      There are two things here - one, generally about upgrading perl, and people already covered that.

      And another one - writing new app for a platform, and you can solve that by using PAR, create your app, and then compile it to elf file that you can safely run on your target solaris server.

      This is a great way for packing apps without touching target system, I do that even if on target platform there already is modern perl available - this way the problem of installing myriad of required modules is solved in one place.

      This will work as long as you're not using Gtk,

    Re: Solaris, Perl 5.8 and use 5.005
    by doran (Deacon) on Mar 09, 2005 at 01:39 UTC
      Another place to look is in the INSTALL file which comes with the perl source. Of particular interest would be the "Coexistence with earlier versions of perl5" section, and possibly the earlier "installing perl under a different directory" area of the "make install" section.

      I don't know if the above will help with your specific problem, but I found it quite useful in understanding what happens when I install a newer version on top of an older one. It also showed me why I had a different perl version in /usr/bin than I had in /usr/local/bin.
    Re: Solaris, Perl 5.8 and use 5.005
    by mhearse (Hermit) on Mar 09, 2005 at 04:06 UTC
      I recently did this on Solaris 7. The best solution I found was to build Perl-stable from source. Using the gcc 3.4 package from sunfreeware.com, I had no problems. I put the new distribution in /usr/local, to avoid overwriting the stock install. I really don't like the idea of having two Perl's in the PATH. I know there is a lot of hype about breaking programs when overwriting the default install, but I don't see how. You can always place a sym link to perl in /usr/bin.

    Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Node Status?
    node history
    Node Type: perlquestion [id://437185]
    Approved by Joost
    Front-paged by friedo
    help
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others drinking their drinks and smoking their pipes about the Monastery: (8)
    As of 2014-09-19 22:51 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      How do you remember the number of days in each month?











      Results (151 votes), past polls