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:
PPA for PHP 5.4
PPA for PHP 5.5
PPA for PHP 5.6
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
As always, see Ubuntu's main page on community support
options.
askubuntu.com, #ubuntu-server on IRC
(Freenode) and the Ubuntu Server mailing
list are
appropriate venues.