Ubuntu 14.04 LTS ships with PHP 5.5, which is a significant upgrade over PHP 5.3 as found in 12.04.

PHP 5.5 actually first appeared in 13.10, though of course if you intend to do an LTS to LTS upgrade, you won't notice this until now.

PHP upstream introduced some incompabilities in this update, and recommend testing before upgrading production environments. For more details, see the PHP migration guide.

Getting PHP

PHP 5.5 is available in the main Ubuntu repository for Trusty, so apt-get install php5-cli (or libapache2-mod-php5 , etc) will suffice. Ondřej Surý, the primary Debian PHP maintainer, also maintains a series of PPAs on Launchpad if you need a different version. Taking a quick look at Ondřej's Launchpad page, I see:

Thanks to Ondřej for kindly taking the time to maintain these PPAs for the community.

Help Wanted

Ondřej Surý, the Debian maintainer of PHP, posted a request for help with PHP Debian packaging. If you are an available Debian developer or maintainer, please join him. Helping with Debian PHP packaging also helps Ubuntu, since Ubuntu's PHP packages are heavily based on Debian's work.

Upstream dissonance

There are a few areas in which multiple distributions (at least the Fedora and Debian families) patch PHP, but these patches have not been taken upstream. Perhaps I'm mistaken, but I believe that most PHP users consume PHP through a distribution, so it does not seem ideal that multiple distributions carry these patches instead of their changes being adopted in upstream directly. I'd love to see better collaboration with upstream in these areas so that these particular distribution patches become unnecessary.

I mention some of these differences here since the differences appear to have affected some Ubuntu users.

JSON module

PHP upstream ship a JSON module whose licence is not considered acceptable to distributions. This was reported and accepted in Debian bug 692613, and Fedora also concurs.

As a workaround, Remi Collet from Fedora removed the JSON module, but arranged to ship a PECL module that builds JSON from an external, API compatible source that is not based on the upstream that is licensed dubiously. Debian fixed the licensing problem by doing the same thing.

Ubuntu follows the Debian lead by default, so Trusty also ships without the upstream core PHP module. Instead, since Trusty, the php5-json module is automatically brought in as a dependency. Users will still see an API-compatible JSON module available; it is just an alternative implementation that is more acceptable to Debian (and to Fedora).

Note that there is a claim in bug 1287726 that there exist edge cases where behaviour has changed. This bug is waiting on a volunteer to fix behaviour in the alternative JSON implementation. It sounds like this other upstream would be happy to take the change. This is an unfortunate consequence of the situation, but at least there are no fundamental disagreements on how to fix this. It is "just a bug" with a simple technical solution; we just need an expert in the area to take a look and fix it.

Some background: the Debian Free Software Guidelines (DFSG) ensures that Debian is free to install and use by everyone, without restriction. Ubuntu is primarily based on Debian, so inherits this status. Much of the hard work to make this reality has been done by the Debian FTP masters who have painstakingly reviewed every package in Debian (and consequently most of the packages in Ubuntu) to ensure that this is the case. So all software shipped by Debian must comply with the DFSG, and the PHP JSON module does not meet this requirement.

The other side of this argument is that the PHP JSON module is too important to compromise quality over a petty licensing issue. Why can't distributions just ignore the nonsensical clause?

This issue has brought out many angry people on both sides of the debate, and there have been some flames over this. I would like to remind readers of the Ubuntu Code of Conduct:

Disagreements, social and technical, are normal, but we do not allow them to persist and fester leaving others uncertain of the agreed direction. We expect participants in the project to resolve disagreements constructively. When they cannot, we escalate the matter to structures with designated leaders to arbitrate and provide clarity and direction.

In Ubuntu, we make decisions based on consensus, or (rarely) through leadership when necessary. Right now, Ubuntu has not specifically made any decision on this point. We are simply following Debian by default, which is what we do unless we have particular reason to diverge.

Please be constructive about this issue. Remember: Ubuntu is a community project, and we have a well defined path for making decisions. The appropriate avenues to make a change in Ubuntu on this point is to first try to achieve consensus (eg. on mailing lists), and failing that, to take the matter to the Ubuntu Technical Board.

More discussion can be found in the upstream bug and reddit thread.

Timezone handling

In a distribution, users expect to set a system setting once, and to have all applications to pick up that setting automatically. This includes, for example, the system timezone setting.

This principle also applies to system timezone updates. When daylight savings time rules change in some country or other, users expect to have these picked up in a single system update, and for all applications to immediately use this new data.

PHP upstream disagree on this point. PHP as shipped by upstream requires the system timezone to be manually set in php.ini . PHP also uses its own inbuilt timezone rule database, so users do not receive rule updates without also bumping the PHP version with a new upstream tarball.

So Fedora, Debian, Ubuntu (and others?) all patch PHP to make it use the system timezone setting and the system timezone database.

More information is available in a comment in Debian bug 618462.

As upstream releases changed, we had a couple of regressions in the past in bug 1069529 and bug 1244343. I managed to sort these out (and submitted patches to Debian also), so I think we now have this functionality properly nailed in Trusty.

As all distributions are carrying this patch (written originally by Remi Collet of Fedora, I think), it would be nice if upstream PHP could take this patch too. But my understanding based on the Debian bug above is that they are reluctant.

libgd

PHP includes a GD module, which provides an API to various graphics operations. PHP upstream bundle this library. But distributions prefer to use a single version of a library shipped separately, rather than using the versions shipped bundled inside upstreams.

The reasons for this are well documented in Fedora's No Bundled Libraries Policy and in Debian's Upstream Guide, so I won't repeat their justifications here.

In PHP's case, they effectively forked GD by adding functions that were not available upstream, and then made these functions available in the PHP GD API. Since distributions used the upstream GD library, this meant that PHP programs written against this API failed to work on PHP as shipped by distributions, since they used missing functions that were not available.

Bug 74647 contains the details. I believe this is a mostly solved problem now, as PHP upstream did focus on trying to get all of the required functions accepted in GD upstream. There is one report that there is one remaining function ( imagerotate ) that is still not available upstream, and thus not in distributions that ship PHP.

I am pleased to note that it does appear that upstream are working on the problem, so I hope that this issue will completely go away in a future release.

Thanks

Thanks to Ondřej Surý for his relentless effort in keeping PHP maintained in Debian, for monitoring PHP bugs in Ubuntu, and for maintaining PPAs for PHP in Ubuntu.

Getting help