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.
| [reply] |
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.
| [reply] |
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.
| [reply]
[d/l]
[select] |
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.
| [reply] |