The latest Long Term Support (LTS) release from Ubuntu has been with us for a bit over a month now, and I love it so far, on my laptop. This is Lucid Lynx 10.04, and will be supported until 2013 on the desktop, and more importantly, until 2015 on the server.

My servers are still on 8.04 though, the previous LTS, for good reason. 10.04 has PHP 5.3. While this is generally a better PHP, it has some compatibility issues with many Drupal, mainly for contributed modules, but some in core as well.

The long term solution to this is to find all PHP 5.3 compatibility issues and fix them in the code. This is a lengthy process though, and will not happen overnight.

So, in the meantime, there are several solutions for running PHP 5.2 on Lucid, some better than others.

In this post, we examine the different approaches, and the merits of each.

Approach 1: Installing Karmic's PHP 5.2 packages

The most common approach is to install Karmic 9.10's PHP 5.2 packages on 10.04. This has been reported to work for many, such as here, here and here.

The detailed instructions were originally posted here, and the following script is a refinement of that approach:

#!/bin/sh

# Script to install PHP 5.2 from 9.10 on 10.04
# And pin it so it does not get updated

PKGS=`dpkg -l | grep php | awk '{print $2}'`

apt-get remove $PKGS

sed s/lucid/karmic/g /etc/apt/sources.list | 
  tee /etc/apt/sources.list.d/karmic.list

mkdir -p /etc/apt/preferences.d/

for PACKAGE in $PKGS
do
  echo "Package: $PACKAGE
Pin: release a=karmic
Pin-Priority: 991
" | tee -a /etc/apt/preferences.d/php
done

apt-get update

apt-get install $PKGS

This is not the best solution though for many reasons, the main one is that these packages were compiled against libraries built for 9.10 and not 10.04. There is always a risk of unpredictable things happening when doing such a thing.

It also requires the packages to be "pinned" so no future security updates would be provided, unless 9.10 gets them too.

I also found no easy way to pin with aptitude, rather than with apt-get.

Approach 2: Proper PHP 5.2 packages, compiled for Lucid, installed manually

The fine folk at The Jibe took this one step further and built PHP 5.2 .deb packages for Lucid.

What this approach provides is that the packages are built against Lucid headers, and therefore solves the issue mentioned above.

What this solution suffers from is the lack of a repository. This means that the packages have to be downloaded and installed manually. Also, if you install them directly via the dpkg -i command, there may be unmet dependencies if you have not installed PHP 5.3 previously. This can be overcome by running the gdebi command instead, available in the "gdebi-core" package.

Still, the previous approach is too manual, and there is no way to check automatically for security updates for example.

Approach 3: Proper PHP 5.2 packages, compiled for Lucid, installed from a repository

So, the best solution, is to install from a repository
Ralph Janke's PHP 5.2 repository for Lucid

If you have the package "python-software-properties installed, you can easily add the repository using the command:

add-apt-repository ppa:txwikinger/php5.2

That will install the GPG key for security verification.

If you are using apt-get, then you need to create a file called /etc/apt/preferences.d/php for pinning the versions, so they remain at 5.2 and don't get upgraded to 5.3 when you run apt-get to upgrade your installation.

Put this in the file:

Package: libapache2-mod-php5
Pin: version 5.2.10*
Pin-Priority: 991

Package: libapache2-mod-php5filter
Pin: version 5.2.10*
Pin-Priority: 991

Package: php-pear
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-cgi
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-cli
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-common
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-curl
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-dbg
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-dev
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-gd
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-gmp
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-ldap
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-mhash
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-mysql
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-odbc
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-pgsql
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-pspell
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-recode
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-snmp
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-sqlite
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-sybase
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-tidy
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-xmlrpc
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-xsl
Pin: version 5.2.10*
Pin-Priority: 991

Then you do "apt-get update" and the right packages are either pulled in due to installing them directly or indirectly through dependencies.

That works fine for apt-get.

If you are using aptitude instead of apt-get, then skip the above pinning file, and tell aptitude to hold the version of PHP to what you have installed.

aptitude hold `dpkg -l | grep php | awk '{print $2}'`

Alternatively, you can do:

for PKG in `dpkg -l | grep php | awk '{print $2}'`
do
  echo "$PKG hold" | dpkg --set-selections
done

I am not sure if the above two commands are enough to stop aptitude from upgrading the packages to 5.3 if a new release comes by. If you find a better way to let aptitude handle this, please post it below.

Resources

Some further links that you may want to check:

  • Slicehost forum post on the topic of PHP 5.2 downgrade, since PHP 5.3 breaks many applications, such as Drupal, MediaWiki and others.
  • Another article on Lucid 10.04 for web development. Touches on the PHP downgrade topic.

Comments

Sat, 2010/06/05 - 22:07

Why should I downgrade a perfectly stable and powerful system for a few lazy programmers who had one year to make minor fixes to their code. I approve with Ubuntu which in 10.04 is forcing them to do this. I am using Drupal which for me does not have any problem. Only a few modules I use are problematic and give errors but they can be avoided, and I made them hide the errors for the general public and record them only o=in the log. Everywhere I hear how to downgrade, downgrade, downgrade... People, upgrade is good...

Sat, 2010/06/05 - 22:37

Stability trumps shininess ...

When you are faced with several modules that you are running not working on the new LTS, then what are your options?

a) Stay on the old LTS (it is still supported for many years to come).

b) Fix all the modules that are broken, and then you are either left with your own fork of them, or have to do yet extra work to contribute back the patches.

c) Downgrade to PHP 5.2.

All these are temporary solution, and will vanish when the modules are upgraded to be PHP 5.3. It is just a matter of time. Until then, these are the options.

Tue, 2010/08/10 - 11:48

I am using 9.10 on my dev box. Working flawlessly.
Would you recommend using 9.10 in production, or moving to 10.04?

Thank you - and I really appreciate the great articles and presentations you have given!

-johnc

Tue, 2010/08/10 - 11:58

I always run production sites on an LTS version. At present 8.04 LTS has all what I need. This means PHP 5.2, not PHP 5.3 which has issues with some applications (e.g. some contributed modules in Drupal).

Obviously 10.04 is also LTS and will last 2 years longer than 8.04, but it has PHP 5.3 only on it. PHP 5.2 is available through Ralph Janke's PPA, but I am hesitant to try that for production sites.

So, I am staying with 8.04 until the above modules are PHP 5.3 safe, then I will jump to 10.04.

In all cases, don't use non-LTS versions, since they are short lived and you will lose even the repository after 18 months from release.

Fri, 2010/08/27 - 10:34

See following errors when installing php5-interbase

The following packages have unmet dependencies:
php5-interbase: Depends: phpapi-20090626+lfs
E: Broken packages

I cannot install

Thu, 2011/09/22 - 15:21

You need to be sure that all packages are added to the file in /etc/apt/preferences.d or you will run into broken dependencies.

Sun, 2010/06/06 - 07:46

... is I think, to always develop with your PHP error reporting set to E_ALL rather than the more common E_ALL & ~E_NOTICE. This will show you where you are using depreciated techniques which would've caught 90% of problems of moving from 5.2 to 5.3.

Sun, 2010/06/06 - 11:18

That is really good advice, and everyone should be doing that.

The reality is, not many have been doing it.

Also this applies only to your own code, not code that you download from drupal.org.

When you download the code, you want to think about long term maintenance for it. Forking it makes you an island, and makes it hard to get synched up with future releases. You can mitigate some of that by having them under revision control, but it is never fully automated nor labor free.

Therefore, for less work in the future, either use PHP 5.2 for now, and wait for the problem modules to be 5.3 compatible.

Tue, 2010/06/08 - 00:58

Yeah I didn't mean to imply forking. I meant "we module maintainers", and "we custom module writers" should be doing our development with all PHP errors, warnings, notices, etc. blazing in our faces.

Pages

Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting