perl upgrade, req to understand which modules to install

Hello

I am not used to perl myself but have to upgrade different perl installs
on a server. There are many previous perl versions which we want to
upgrade to say, perl 5.8.0 (as an example). There are hundreds of perl
scripts on the server which use different versions.

what's the best path to follow?

what I have done is this:
- find all modules on each perl installation. there are many differences
versus the reference version (5.8.0 in this example)
- find all 'use' and 'require' on all perl scripts. I have a file with a
sort | uniq of these. but there are a lot of options which I really
don't know yet if are extra modules by themselves (as I have not really
used perl before) This approach would save me from install unrequired
perl modules on the reference version.

I think the second option is the best, but then I have this kind of
list. Are these different submodules, or just options for the same
module:

CGI
CGI ':all'
CGI qw (:standard)
CGI qw(-oldstyle_urls :standard)
CGI qw(:cgi)
CGI qw(:standard -private_tempfiles)
CGI qw(:standard)
CGI qw(param)
CGI qw/:all cgi-lib/
CGI qw/:all/
CGI qw/:standard/


Thanks in advance

Re: perl upgrade, req to understand which modules to install

On 2006-10-02 18:54, Gabriel Orozco wrote:
> I am not used to perl myself but have to upgrade different perl installs
> on a server. There are many previous perl versions which we want to
> upgrade to say, perl 5.8.0 (as an example).

Just in case it isn't only an example: Avoid 5.8.0. As the first release
of the 5.8.x series it had many problems which were fixed in later
releases. Use the latest 5.8.x release if possible.

> There are hundreds of perl scripts on the server which use different
> versions.

Since there are already many perl versions on the server, I assume you
can install the new version without uninstalling the old ones. This
allows you to switch a few scripts at a time - you don't have to switch
all of them at once.

Also: Do you have a test server where you can test the scripts before
changing them on the production server?

> - find all 'use' and 'require' on all perl scripts. I have a file with a
> sort | uniq of these.

That's also my first step at compiling a list of modules I need to install.
However, I have the advantage that I wrote most of the perl scripts
which are running on our servers.

> but there are a lot of options which I really don't know yet if are
> extra modules by themselves

Generally you can ignore the options, as they just modify the behaviour
of the module (e.g., they are often used to tell the module which
functions should be exported). In rare cases an option may cause a
module to load another module, but

a) you cannot infer this from the use command - you have to read the
docs, and

b) this can also happen after use. For example, the DBI module decides
which of the DBD::* modules it has to load only when connect() is
called.

So this is a way which may require quite a bit of work and perl
knowledge.


> (as I have not really
> used perl before) This approach would save me from install unrequired
> perl modules on the reference version.
>
> I think the second option is the best, but then I have this kind of
> list. Are these different submodules, or just options for the same
> module:
>
> CGI
> CGI ':all'
> CGI qw (:standard)
> CGI qw(-oldstyle_urls :standard)
> CGI qw(:cgi)
> CGI qw(:standard -private_tempfiles)
> CGI qw(:standard)
> CGI qw(param)
> CGI qw/:all cgi-lib/
> CGI qw/:all/
> CGI qw/:standard/
>
>
> Thanks in advance


--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: perl upgrade, req to understand which modules to install

Peter J. Holzer wrote:
> On 2006-10-02 18:54, Gabriel Orozco wrote:
>



>
>
>>There are hundreds of perl scripts on the server which use different
>>versions.
>
>
> Since there are already many perl versions on the server, I assume you
> can install the new version without uninstalling the old ones. This
> allows you to switch a few scripts at a time - you don't have to switch
> all of them at once.
>
> Also: Do you have a test server where you can test the scripts before
> changing them on the production server?
>
>

These are both _really_ good ideas, since module upgrades are
occasionally incompatible. DBD did this to me once -- the upgrade added
warning messages for things like running off the end of a cursor, and
supression required clearing an attribute that the old version didn't have.

If you're desperate, a test server of a different architecture than the
server you're converting may be better than nothing - unless you're
converting Windows, which I assume you're not since you're doing things
like 'sort | uniq';

One of the complications is that modules come in packages. Module CGI
happens to come in package CGI, but module LWP::UserAgent (and a lot of
others) come in package libwww-perl.

Unless you are using ActivePerl, you should find somewhere in each
Perl's module directories a file called 'perllocal.pod'. This will list
each package that has been installed in that version of Perl. This is a
superset of what you want, but may be useful as a reference.



Tom Wyant