migrate perl program

gehu has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: migrate perl program by choroba (Cardinal) on Dec 02, 2014 at 14:57 UTC
It depends. RHEL3 is from 2003, so it probably features 5.8.0 or the like. RHEL7 is current (perl 5.16?), which means a lots of deltas to study. لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ	[reply]
Re^2: migrate perl program by McA (Priest) on Dec 02, 2014 at 15:20 UTC
Hi choroba, do you really think the Perl changes matter? Assuming it's Perl 5.8 than it means that newer features are never used and shouldn't be a problem. In my opinion there are two main fields: Bugfixes which cause different behaviour in old code. Changes and bugfixes in used modules. My first anaysis would try to collect all used modules. McA	[reply]
Re^3: migrate perl program by choroba (Cardinal) on Dec 02, 2014 at 15:23 UTC
There might be some deprecations, too. I had to remove many `defined %hash` even from 5.8.6 code. But you're right, modules might be a bigger problem, especially if they're XS but not maintained anymore. لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ	[reply] [d/l]
Re^2: migrate perl program by hippo (Archbishop) on Dec 02, 2014 at 15:57 UTC
If those version numbers were guesses, they are very good ones! According to DistroWatch the perl versions packaged with RHEL3 and RHEL7 are 5.8.0 and 5.16.3 respectively.	[reply]
Re^3: migrate perl program by choroba (Cardinal) on Dec 02, 2014 at 15:59 UTC
Well, I consulted Wikipedia and perlhist - the Perl history records. لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ	[reply]
Re: migrate perl program by davido (Cardinal) on Dec 02, 2014 at 18:45 UTC
While Perl's design philosophy has aimed to maintain backward compatibility as much as possible, there are conditions that may be problematic. I started to list them, and realized that the more I listed the more I was coming up with, and that listing them isn't the right approach. The right approach is to set up a test server with your new environment installed on it, migrate the app, and begin testing. Hopefully a good test suite is in place for the application. If not, you're going to have to get started on implementing that as well. Ok, I can't resist... here's a massively incomplete list of potential issues. It may also be massively hyped. ;) Modules that were part of the Perl core as of 5.8 have been dropped as of more recent versions of Perl. Modules that implement some feature now don't implement that feature anymore. XS modules may fail spectacularly, as the XS/guts/perlapi spec has changed little by little over the past decade. Handling of Unicode, and even the `utf8` pragma have changed over the past decade or so. Hash randomization ordering has changed. Code that relies on some form of consistency may break. External shared libraries that some XS module wraps may have changed over the years in ways that are incompatible. A newer XS-module with an older external library, or vice versa may be problematic. If the program uses pseudo-hashes or some other obscure feature of 5.8, it will probably break under versions of Perl that have eliminated that obscure feature. Some special variables such as `$*` have changed or been eliminated. Bug fixes along the way may also have created undiscovered bugs. At minimum you must test in a non-production setting. Dave	[reply] [d/l] [select]
Re: migrate perl program by FloydATC (Deacon) on Dec 02, 2014 at 16:27 UTC
Try to put together a list of Perl modules in use, this would help greatly in understanding what kind of problems you might run into. You could try to collect some data on this automatically, for example by using grep. My grep-fu isn't very strong but it should atleast help you get started: `grep -r "^use [0-9a-zA-Z\:];" /home/` Also, I've found that well-written perl code usually survives longer. No "use strict/use warnings"? Lots of global variables? No SQL placeholders? Manual extraction of form parameters as opposed to using the CGI module? These are usually signs that the migration is going to take a while. Not necessarily because more things break, but because poorly written code can be notoriously hard to troubleshoot and you end up having to rewrite a lot of code that deserved to die. I know this all too well, because I've just spent two days migrating my own private web server with scripts dating back to last century. It was even worse than I feared :-P -- FloydATC Time flies when you don't know what you're doing	[reply] [d/l]
Re^2: migrate perl program by gehu (Initiate) on Dec 02, 2014 at 17:08 UTC
thanks for your responses, but my scripts are simple, long but simple, a lot a scripts for transfer FTP. The modules which frighten me, are perl-Net-SSLeay-1.30-4.EL3, perl-Crypt-SSLeay-0.51-4, perl-DBI-1.32-9. I don't use strict/warnings in my scripts. I've been reassured by your analyses, I am going to launch the first tests. i've got a feetback.	[reply]
Re^3: migrate perl program by GrandFather (Saint) on Dec 02, 2014 at 20:26 UTC
So a really good first step would be to add strictures to your code before you port it and clean up any issues raised on the old system. If possible it would also be smart to add some regression tests so you can have some confidence behavior hasn't changed in important places during the migration. Also run through checking that system calls are checked for errors and handled correctly - if you are moving to a new system filed and directories may have moved around in surprising ways and file operations may begin failing as a result. Perl is the programming world's equivalent of English	[reply]
Re: migrate perl program by wazat (Monk) on Dec 02, 2014 at 15:39 UTC
You do not provide enough context for anyone to provide meaningful advice. The best we can do is answer with vague generalities. Ideally you should have regression tests for your programs that you can use to verify that they run correctly under the newer OS. In my experience, perl programs written under older versions of Perl work fine under newer versions. The risks may lie in programs that depend on modules that have undergone changes that are not backward compatible. There are also risks involving progams depend on the operating environment. There are risks that modules you depend on that were bundled with RHEL3 are not bundled with RHEL7. Core perl modules will probably be fine. Given that you haven't given any indication of what kinds of programs you have, or what modules they depend on, it is impossible to give an answer to your question. All that you tell us is that you have a big ball of programs. In my experience, well written progams have the fewest problems with changes in operating environment. Badly written programs can break under the slightest changes. Badly maintained programs are also vulnerable. If you don't know anything about the programs, the answer to your question is "maybe". Good luck.	[reply]
Re: migrate perl program by jellisii2 (Hermit) on Dec 02, 2014 at 15:06 UTC
There seems to be a lot of detail missing, unless you're just looking for the information that choroba put up... perhaps How do I post a question effectively? may help you refactor your post to get more information if you want/need it.	[reply]
Re: migrate perl program ( qr ) by Anonymous Monk on Dec 02, 2014 at 21:16 UTC
will my perl program work fine in new system? it probably will, but it might not, your test suite should be able to catch the difference so that you can fix it very quickly Re: How can check whether new version of module is compatible with my code or not? (test suite) If you're using qr defaults changed `re => qr/$re/ms, # need /ms for 5.12 and up` Re: Parse::Report - parse Perl format-ed reports. and Other incompatible changes perldeltas - every perl*delta in one file with each version properly linkable Read more... (1114 Bytes)	[reply] [d/l] [select]