Well it will depend on the modules but if you build your own Perl part of the build/install is to search for old versions of Perl and ask if you want to add their @INC to the @INC of the new. You can still do something similar if using a package but it's more fun to build your own.
This neatly leads onto another issue. If you've done this in the past so now have several perl library sets, is there an automatted way to remove old versions of modules where newer ones exist, ie module::something v1 was installed by Perl 5.6 and is in /usr/local/lib/perl/5.6.0...., v2 was built with Perl 5.8 and is in /usr/local/lib/perl/5.8.x....
If you build the new module with the same Perl as the old it overwrites the old module, is there a nice way to remove the old version, ideally when installing the new, for building with a newer Perl? | [reply] |
So...
1) include the old INC values
or
2) do a complete rebuild and reload of the modules
correct?
Thanks
John
| [reply] |
I assume a new install of PERL 5.8.8 would require all our modules to be reinstalled.
Well ... that's definitely not true wrt Mandrake linux, and it's definitely not true wrt Win32. I doubt very much that it's true wrt Solaris 10, but I don't really know. With my Mandrake linux, all I had to do was install perl 5.8.8, and the relevant 5.8.7 directories were automatically added to @INC, thereby alleviating any need to re-install modules. On Win32, however, that didn't happen. But all that was necessary was to copy the entire 5.8.7/site/lib/ directory to 5.8.8/site/lib/. You could do the same thing on Solaris if necessary.
I also wonder if you need to 'use diagnostics;'. I suspect that if the diagnostics module is not loaded, then the problem will go away.
Cheers,
Rob
| [reply] |