in reply to Re^2: Issue in migration of Perl code from 5.6.1 to 5.8.6
in thread Issue in migration of Perl code from 5.6.1 to 5.8.6

Yes, what I called "stock perl" is the Perl that comes with your installation of Linux.

In my opinion, you shouldn't remove whatever you copied, because the risk of you removing too much is high.

If you plan on running the application with the stock Perl at the customer's site as well, it's good to test it locally first. This still doesn't make it really convenient because the customer might choose to upgrade the OS and then the stock Perl will get upgraded without you getting further notice.

The package manager of your Linux distribution is documented in the documentation of your Linux distribution. While Perl is widespread and some distribution package managers are written in Perl, Perl has little involvement with Linux distributions and thus does not document Linux distribution package managers. A good package manager automatically includes all dependent modules, but I don't know whether that's the case for RedHat.

In my first response, I listed the approaches in order of descending quality.

You can only find out that you have installed all the required modules if your application runs flawlessly.

  • Comment on Re^3: Issue in migration of Perl code from 5.6.1 to 5.8.6

Replies are listed 'Best First'.
Re^4: Issue in migration of Perl code from 5.6.1 to 5.8.6
by ja3 (Initiate) on Feb 09, 2009 at 18:38 UTC
    Hi, Thanks again! Just in case, if I choose not to go with "stock perl", how can I install my perl? Does that mean have another perl folder containing complete perl installation?If that's true, not sure if I can just download Perl 5.8 version from CPAN... I have a list of files that I copied over in case I want to back them out. At this point, I am a little confused as to what direction I should take...But thanks for your advice.
      Does that mean have another perl folder containing complete perl installation? If that's true, not sure if I can just download Perl 5.8...

      Essentially, yes, the complete Perl installation (binary, modules, etc.) can be put under a specific directory (plus subdirectories, of course).

      Note however, that if you download a prebuilt Perl distribution, there will be some installation path hardcoded in the binary, which means you can't arbitrarily move around the installation — for example, if the original hardcoded path is /opt/perl, you can't simply put it into /usr/local/perl/5.8.8 or similar. The reason for this is that perl needs to find its associated Config.pm, which then contains all the other settings, like where to look for the modules that belong to that version, etc.  (This applies to unix-ish systems only, on Windows this is a non-issue.)

      For this reason, you might want to build your own perl from source, so that you can specify the installation path yourself at build time...

      That said, there is a new feature "relocatable @INC" (i.e. Configure option -Duserelocatableinc, introduced with 5.10), which effectively allows modules to be found relative to where the perl binary is installed — IOW, the installation can now be moved around freely.  If you're lucky, you might find a prebuilt perl v5.10 that's been configured with this option.

        If I end up installing separate Perl, how can I run the code under this version in stead of stock perl? Thanks!

      I would imagine that the approach to using the stock Perl or not should be cleared with your customer, because in the end, you have to ship your program to their machine.

      You can download Perl from CPAN or http://perl.org.

      If you are not familiar with sysadmin stuff, you will either have to become familiar with it yourself, or get a sysadmin to consult with.