Comments on: Upgrading from Perl 5.8

By: Dave Hodgkinson

Dave Hodgkinson — Mon, 21 May 2012 09:45:56 +0000

Just went through something not too dissimilar to this at the BBC. Luckily, we could get the specific versions of modules off live as they’d all been cpan2rpm-ed before installing, then a trawl through backpan using Schwern’s Backpan::Index module (which requires a recent DBIC, unlike our system, which ribasushi helped to find out why we needed the old version) and the system was largely recreated.

We looked at carton but it didn’t really scratch the particular itch we had.

By: Pradeep Pant

Pradeep Pant — Mon, 20 Feb 2012 11:06:37 +0000

Thanks Tim for nice write up. In fact, we are still using Perl 5.8.5 on Cent OS 4.6 in production environment. We also use some of the very old CPAN modules, some of them are even more than 10 year old and not updated thereafter. Now, we really need to upgrade to newer Perl with Cent OS 6.x or so. I am sure that your article will help me in up-gradation process. Thanks

By: What’s actually installed in that perl library? « Not this…

What’s actually installed in that perl library? « Not this… — Wed, 16 Nov 2011 22:08:05 +0000

[...] key part of my plan for Upgrading from Perl 5.8 is the ability to take a perl library installed for one version of perl, and reinstall it for a [...]

By: TimBunce

TimBunce — Thu, 25 Aug 2011 09:02:17 +0000

I’ve not run into a cyclic dependency problem yet, thankfully. I guess ours were recent enough.

By: 0tux

0tux — Thu, 25 Aug 2011 07:41:04 +0000

One problem still unmentioned: Some modules cause cyclic dependencies. Test::More and Test::Harness are a very icky combination. They require each other. If both are recent enough, you won’t ever see a problem, but trying to update those two on a perl where both are too old wil make you want to rip out your hairs. I bet there are other cyclic problems too, but this one is on the basis of the toolchain.

By: TimBunce

TimBunce — Mon, 25 Jul 2011 16:05:31 +0000

Another approach to discovering exactly what versions of what distributions are installed is BackPAN::Version::Discover. I’m trying it out now.

(On my initial run it had 39 distributions in dists_not_matched, 106 modules in no_dist_found, and seemed to be confused by the archlib, so there were 600+ modules in skipped_modules->bad_mod_info like “x86_64-linux-thread-multi::Moose”.)

By: TimBunce

TimBunce — Fri, 22 Jul 2011 21:11:27 +0000

It’s not a rule. The dists don’t have a choice. The issue is binary compatibility of compiled extensions. When an extension is built against perl 5.X it generates a binary shared library object (typically a .so file on unix). That object file embeds knowledge of the internals of the perl 5.X it was built against. Since perl 5.10.0 it’s guaranteed that minor versions of perl 5.X will remain binary compatible, but the next major release, perl 5.Y, almost certainly won’t be.

By: rwstauner

rwstauner — Fri, 22 Jul 2011 14:57:04 +0000

I didn’t realize that the rule was that you could share installed CPAN modules according to perl _major_ version…
That’s an interesting tip.
I’ve always been wary of that.
I wonder if there are any dists that don’t follow that rule.

By: TimBunce

TimBunce — Thu, 21 Jul 2011 19:42:30 +0000

I’m not sure it’s a good fit for our needs, but carton is certainly a very interesting project. Thanks.

By: mpetersnc

mpetersnc — Thu, 21 Jul 2011 16:52:26 +0000

I think it’s also a good idea to mention Miyagawa’s carton project (https://metacpan.org/module/carton). This would let you explicitly list the dependencies of your project even down to the versions you want and have them installed in a project specific directory. Obviously won’t help with completely legacy code, but once you get the list of what you have installed and their versions, it’s a nice approach so that you never have to do that again.