Ubuntu has recently offered a Perl upgrade to 5.10 and I accidentally accepted the upgrade. Unfortunately, since our development Perl is 5.8.8, I've encountered a few annoying problems. Since many people are confused about how to do this, I decided to slog through and figure it out. Not fun. The answers to the various problems are scattered hither and yon, making this a very unpleasant process.
First, you need to get Perl and apply a regex patch which closes a security hole (many thanks to Rufus Cable for alerting me to the patch):
wget http://www.cpan.org/src/perl-5.8.8.tar.gz
wget ftp://ftp.cpan.org/pub/CPAN/authors/id/N/NW/NWCLARK/regexp-5.8.8.patch
tar xzf perl-5.8.8.tar.gz
cd perl-5.8.8
patch -p1 < ../regexp-5.8.8.patch
rm -f {config,Policy}.sh
sh Configure -de
Be sure to read the INSTALL file for more information about the Configure options.
At this point, everything should be fine, but you can't run make yet. Actually, you can run make, but it will likely fail. Fortunately, you can keep fixing errors and rerunning make until all errors go away.
The first problem is a strange "You haven't done a make depend yet" error. As it turns out, this is because Ubuntu has decided to link /bin/sh to /bin/dash instead of /bin/bash. It's a faster shell, but not only does it not support everything bash does, it also is less tolerant of errors. The makedepend file has an unterminated quote string, so doing this gets you over the first hurdle:
sudo ln -s /bin/bash /bin/sh
Be sure to change the symlink back after you're done if you want dash instead of bash (note that using a correct shebang line at the top of your bash scripts makes this a non-issue for you).
If you've already tried to run make, you might see this error:
makedepend: Already running, exiting
That's because it previously exited abnormally (anyone remember "abend"?) and left a .depending directory lying around. Simply remove this directory and rerun.
If you run make now, you might hit the second error:
No rule to make target `', needed by `miniperlmain.o'.
Apparently, we filter out some of the gcc output, but it's changed over time and we missed this. The following fixes it:
perl -i~ -nle 'print unless //' makefile x2p/makefile
That command tells perl to edit those files in place, reprinting all lines except those containing the string <command-line>. If for some bizarre reason you don't yet have Perl installed (or if it's broken), you can edit those files manually, but it's tedious and error prone.
You can rerun make and it might be fine, but you might hit this error:
SysV.xs:7:25: error: asm/page.h: No such file or directory
Arg! I don't know what this is, but apparently it's related to the linux headers. What I don't understand is that I have them installed (sudo apt-get install linux-headers-$(uname -r)), but page.h is not symlinked in /usr/include/asm/. A locate '/page.h' | grep asm returned many candidates, but the most likely fix seemed like this:
sudo ln -s /usr/src/linux-headers-2.6.28-13/arch/x86/include/asm/page.h /usr/include/asm/page.h
Obviously, the exact page.h you're linking to will vary depending on your architecture.
Assuming all is well and make completes successfully, you can now run make test && make install and you'll have successfully downgraded perl (I would recommend you set your prefix when you run Configure to ensure that you don't overwrite the system perl. You can always set up a symlink to ensure you have the proper Perl running).
I would slap them upside the head just for that!
Re:/bin/sh to /bin/dash
Wonko on 2009-07-30T19:20:35
It'd be more useful too slap the people specifying/bin/sh in their shell scripts that rely on features of bash.
on a Debian based system line Ubuntu it should also be possible to revert the upgrade to bin/perl itself, reinstalling the older 5.8
8 as bin/perl with the Debs, and pinning that version. this may rollback and block an expanding number of dependant upgrades, however.
as is stated elsewhere, having app prod perl be OS bin/perl is dangerous, best to have your own.
Re:backgrading Perl
Wonko on 2009-07-30T19:35:29
as is stated elsewhere, having app prod perl be OS bin/perl is dangerous, best to have your own.
Every time I think about this I am torn. I'm sure most people know the pros and cons of relying on the OS perl install. The big problem that I see is that my operating system provides me with an excellent package manager. A package manager that I have to use anyway, too.
I've always thought it would be useful to have some standardized disto packages that provide an alternate Perl install.
Debian and Ubuntu already have a pretty large percentage of the CPAN modules I need rolled up into packages. However, they're often very out of date. It might be nice to have a set of trusted, tested Perl distro packages that install in
/opt/perl or the like. Core Perl and common CPAN modules would be nice. I may very well be the only person in the world who actually thinks this would be useful. I don't recall ever seeing anyone suggest this before.
Re:backgrading Perl
jjore on 2009-07-31T00:16:39
I do this at work. I build site-specific debian packages for perl, all the dual-life core modules, plus a lot of CPAN.
Re:backgrading Perl
Wonko on 2009-07-31T00:56:29
It would be nice to be able to share the work of building and maintaining these packages. I wonder how many of us there are that actually maintain packages for the software we build from source.
Re:backgrading Perl
jjore on 2009-07-31T02:18:44
Much of my work for this is already pushed to http://github.com/jbenjore/CPANPLUS-Dist-Deb/tree/master which will later be packaged for release to http://search.cpan.org/dist/CPANPLUS-Dist-Deb/.
Re:This is a gigantic how-not-to.
Ovid on 2009-07-30T19:50:31
Can you please be more specific? I do state that people should be setting PREFIX to avoid overwriting the system perl. Should that be highlighted sooner, I suppose. Are there other issues that users should be aware of?
Re:This is a gigantic how-not-to.
Ovid on 2009-09-21T14:32:59
Note to kids finding this on google: since this person never came back and bothered to offer any evidence to support their claim, you can probably ignore it. Personally, if there is a problem here, I'd love to know about it, but frankly, my Ubuntu system has been fine since I've done this.
Re:This is a gigantic how-not-to.
doom on 2010-01-21T02:11:39
Slashdot syndrome: he read the title but not the article. The title makes it sound like you're trying to literally downgrade the system perl, but you of course understand how to use PREFIX to install alternative perls.
Thanks for writing this up, by the way: I've been trying to build an old perl, and I had pretty much blundered my way through to just before the last fix you have here-- and I was glad to see that you didn't understand where the problem came from either.