One of the options available to you while building Perl is whether or not it should maintain a grasp on 5.005* versions of your modules. Normally @INC contains just module directories specific to your version of Perl, but this doesn't have to be the case. Watch for "backward-compatibility" options during the configure process.
Normally (or at least this is how I understand it), modules will only put themselves in version-specific directories if there is a reason the module might not be compatible with other versions of Perl. Likewise, we have architecture-dependent directories for the same reason. In theory you can share your Perl library directory to systems using a variety of architectures and versions of Perl without worry, since everything that is unversioned should be compatible with all versions of Perl, and anything in an architecture-specific directory would only be valid for that architecture. (There are exceptions for stuff that links in external shared libraries, that might or might no be present on otherwise identical directories, or might be located in unexpected places.)
So basically, along that line, if you have stuff in a 5.005 directory, it might be there because there's a likelyhood that it's incompatible with 5.6 (though I don't actually know of many/any modules where this is actually the case), and this is sort of a hint that these modules need to be rebuilt for 5.6. | [reply]
[d/l] |
What kind of production systems are you upgrading? I have a Linux box that I upgraded from 5.005 to 5.6 and I lost nothing. In fact, I had to manually delete 5.005 from my system just so I would make sure that I didn't have any old 5.005 modules lying around mucking things up.
Of course, it's always a good idea to just go ahead and reinstall the modules that you need anyway. Many modules contain code that may have been updated since the last time you used them or contain code that doesn't work quite right in 5.6. If you've used CPAN, you should have a log that keeps track of which modules you have installed. You can use that log to update your system.
Another good reason to use CPAN. | [reply] |
I guess you might be worried about custom modules... Just back up all directories in you @INC path (that the one that gets printed out when perl can't find a module). Then upgrade.
Depending on how zealous your package manager is about cleaning up, the modules may or may not be there after the upgrade.
There is no reason to keep old modules if they are still available on CPAN. Backing them up in case somebody made a booboo with the new version of the module may be a good idea, though.
If it were me, I'd just do the upgrade, then deal with the 'missing module' errors as they come. Since perl is very clear about which modules it needs, it should be an easy task to reinstall them. I never knew there was a log of installed modules, but that would be a good way to do it. ____________________
Jeremy
I didn't believe in evil until I dated it. | [reply] |
There have been a few cases when the upgrading of a module lost it some functionality (for example GD.pm when it lost it's gif output capability) but in 99.9% of all cases you will find a newer module will be backward capatible.
| [reply] |
It isn't perfect, but look at CPAN and study the
autobundle function.
Oh, and wait for Perl 5.6.1. I don't know why it isn't
out yet, but it will have a number of important bug fixes. | [reply] |