- Get Stackato
- Why a Private PaaS?
- Features & Benefits
- Stackato by Language
- Compare Editions
- Stackato & Cloud Foundry
- Developer Tools
- Stackato Training
- Professional Services
- Commercial Support
- Code Recipes
Graham Stuart, September 3, 2010
Sooner or later everybody swaps out hardware. Installing the new gear is usually the easy part. How do you get your applications transferred across, as quickly as possible, and make sure they work on the new system?
Moving Perl anywhere is always a calculated risk because Perl isn't designed to be moved around. How large the risk is depends on how much the environment changes. If all that's happening is a hardware refresh, then the existing installation can be transferred onto the same path on the new system with very little risk. (Keep in mind that some common transfer methods will convert links into copies of the original file. This is enough to break an installation.)
At the opposite end of the spectrum are cases where everything changes; hardware, operating system version, Perl version, installation pathe, etc. With these cases there is no realistic hope of transfer. These cases should always re-install from scratch.
Everything else falls into a grey area with a rapidly diminishing rate of return for each additional manual step needed. If only the operating system changes, the results of a simple transfer across will vary depending on how good your O/S vendor is at backward compatibility. We don't recommend this because if something breaks, it may not become obvious until the specific affected library is needed, and you're not starting out with the system in a known or easy to re-create state so it's much harder to trouble-shoot. If you feel you need to try this method, test the install as thoroughly as you can before returning it to production.
If the Perl version changes, or you move from a 32-bit to a 64-bit version, or you change the install path, just about the only thing that can be trusted is pure Perl code. Since there are so many modules with compiled components, and some of the pure Perl code packages are self modifying when they are installed, sorting out which modules can be "transferred" comes down to a choice between trial and error or manual code diving. In our opinion, either method is too much work to be justified.
ActivePerl provides some tools which can speed up a clean re-install. The major problem a re-install poses is getting all the modules you need. PPM has a utility to capture a profile:
ppm profile save MySetup.xml
After installing ActivePerl on the new machine, copy MySetup.xml from the old to the new machine and run:
ppm profile restore MySetup.xml
This will help enormously, but it won't give you exactly what you had before. This method will install the latest versions of your modules rather than the exact versions you were using. Overall, this is probably a good thing. You'll get fixes and features you didn't have before, and you may need the latest versions on your system anyway if you have upgraded Perl or your third party software.
The PPM system has a lot of modules, but you may find that a module you used in the past isn't available. This can happen if a module has been deprecated. It can also happen if the module is incompatible with the version of Perl you want to use, or if the module can't be compiled without the presence of third party software. Watch the output of the "ppm profile restore" command for modules that can't be found. Sometimes these modules can be sourced from other non-ActiveState PPM repositories. If you know ahead of time that modules in your list have to be pulled from other repositories, you can add those repositories to PPM before you run the "ppm profile restore". If a module can't be sourced from any known repository, it is often possible to use the Perl CPAN tools in ActivePerl and PPM to help you compile the modules locally. In the end, there may be a few cases where the best alternative is changing your programs to use a different module.
Subscribe to ActiveState Blogs by Email
Share this post: