© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
Hello everyone!
Thank you for the various comments and updates. And, of course, a special thank you to Ondřej for his work and his PPA.
Brief intro: My name is Nish and I'm looking into the PHP options for Canonical's Ubuntu Server team.
tl;dr (although, please read it!): Our most reasonable options for Xenial are either *only* PHP5.6 in main or PHP7.0 in main (with no PHP release in universe).
A couple of disclaimers up front:
- My thoughts are not exhaustive, so I may have forgotten something. Please do not hesitate to ask as we go. And rbasak, ondrej and others, feel free to correct me as needed!
- While these thoughts are wholly my own opinion, I have discussed them with rbasak and others, so they are considered.
- No official decision has been reached. I would like to hear from community members on my thoughts, and have a reasonable discussion of what is best.
Our current status quo:
- PHP5.6 is in the main component in Xenial
- PHP7.0 is in the universe component in Xenial
To level-set, per https:/
Going forward, there "are" (some are far less realistic than others, but included for completeness) the following options, as I see it. Note that all options only apply to Xenial, the upcoming 16.04 LTS release.
1) Drop PHP5.6 and PHP7.0 from the Ubuntu repositories
Pros:
- No maintenance cost/formal support cost
Cons:
- No form of PHP in the official repositories
- Potentially massive churn of repositories
- No official upgrade path for PHP 5 users in Wily or Trusty.
- Users who do wish to have PHP, must use a PPA (Ondřej's or otherwise).
Conclusion: Not a viable option, end-users expect some release of PHP to be present (and "worst-case", continuity with the version present in 15.10/Wily.)
2) Promote PHP7.0 to main
Pros:
- Users are able to install either PHP5.6 or PHP7.0 in Xenial, as they see fit.
- Users receive support for both PHP5.6 and PHP7.0.
- Upgrade path is clear for the expected common cases:
* Update to PHP5.6 during LTS upgrade (Trusty -> Xenial) [minimize likelihood of disruption on LTS]
* Keep PHP5.6 during Wily -> Xenial [minimize likelihood of disruption on latest release]
* Upgrade to PHP7.0 during Wily -> Xenial [provide latest version of PHP on latest release]
Cons:
- Cost of official support is significant, in terms of bugs and ensuring appropriate security updates occur to the "main" packages.
- Active support for PHP5.6 upstream ends Dec. 31, 2016. Security support for PHP5.6 upstream ends Dec. 31, 2018. Xenial EOLs in April 2021. So that implies at least several years of PHP5.6 security fixes, at least, needing to be maintained. [http://
- Active support for PHP7.0 upstream ends Dec. 3, 2017. Security support for PHP7.0 upstream ends Dec. 3, 2018. Xenial EOLs in April 2021. So that implies at least several years of PHP7.0 security fixes, at least, needing to be maintained. [http://
Conclusion: Probably not tenable due to the support implications.
3) Keep PHP7.0 in universe [maintain status quo]
Pros:
- Minimize the maintenance cost while allowing either version to be installable. [only one supported release, PHP 5.6]
Cons:
- PHP7.0 will not be officially supported (meaning there can be some latency for security fixes, e.g.)
- Not all end-users will consider the implications of main vs. universe, but will only see PHP7.0 available in the repositories and assume it is "supported"
* Per rbasak something similar was experienced with MySQL and Trusty.
- Active support for PHP5.6 upstream ends Dec. 31, 2016. Security support for PHP5.6 upstream ends Dec. 31, 2018. Xenial EOLs in April 2021. So that implies at least several years of PHP5.6 security fixes, at least, needing to be maintained. [http://
Conclusion: This option seems the nicest, but leads to confusion for end-users.
4) Drop PHP7.0 from universe
Pros: No new maintenance cost in Xenial wrt. PHP. [only one supported release, PHP 5.6]
Cons:
- No PHP7.0 in a LTS release until 18.04.
- Users who do wish to have PHP 7.0, must use a PPA (Ondřej's or otherwise).
- Active support for PHP5.6 upstream ends Dec. 31, 2016. Security support for PHP5.6 upstream ends Dec. 31, 2018. Xenial EOLs in April 2021. So that implies at least several years of PHP5.6 security fixes, at least, needing to be maintained. [http://
Conclusion: Might be the safest option.
5) Drop PHP5.6 from main, promote PHP7.0 to main
Pros:
- Minimize long-term maintenance cost in Xenial wrt. PHP [only one supported release, PHP 7.0]
- Get PHP 7.0 "early" in the a supported release.
Cons:
- No clear (obviously safe?) path for users upgrading from a PHP 5 base (Trusty or Wily) to PHP 7 base.
- Users who do wish to have PHP 5, must use a PPA (Ondřej's or otherwise).
- Active support for PHP7.0 upstream ends Dec. 3, 2017. Security support for PHP7.0 upstream ends Dec. 3, 2018. Xenial EOLs in April 2021. So that implies at least several years of PHP7.0 security fixes, at least, needing to be maintained. [http://
Conclusion: Most attractive in terms of adding PHP7.0, but carries highest risk.
A couple of extra thoughts not tied to any specific option:
- Many users (my opinion) wait until at least the .1 release before upgrading the next LTS. So we might be able to provide a release note wrt. PHP to help with the transition for PHP7.0.
- Ondřej's PPA obviously provides a fill amongst many of these options for whatever might be removed. But that puts a great onus of support on him, which is not ideal.
- We need to consider the upgrade path(s), especially how we might leverage php-defaults to minimize the impact to end-users.
I am currently helping examine 5) above. I have run into some issues, but am working through them as quickly as I can:
- In order to rebuild many packages to pull in PHP7.0 dependencies rather than PHP5.6 dependencies, phpunit must be bootstrapped. That has led to a maze of reverse build-dependencies, which is what I'm currently focused on (this is not blocking the decision, but is taking quite a bit of time).
* As part of the bootstrap, I've been removing package build-dependencies on phpunit itself. This in turn means the updated packages have not yet run their own unit-tests. So it might be they all don't technically work, but that is a bridge I will only be able to cross once phpunit is bootstrapped.
- I initially ran into some issues with symfony (which also is heavily used as a build-depends). But after disabling the debug extension (https:/
- I'm currently tracking down a segmentation fault in the xdebug.so library that is causing pkgtools to fail consistently (which in turn is blocking further package building).
- SWIG is not supported with PHP7.0 (yet) [https:/
* php5-exactimage
* php5-gdcm
* php5-vtkgdcm
* php5-geos
* libgv-php5
* php-kolab
* php-kolabformat
* php5-mapscript
* php5-ming
* libow-php5
* libownet-php
* php5-librdf
- February 18, 2016 is the Xenial Feature Freeze. So we are already almost up against a hard deadline. The former point is critical to that (to ensure the update to swig can occur).
- I am hopeful that once I get some of the "fundamental" (read: common) build-dependencies bootstrapped against the PHP7.0 base, I can automate the build-out of the remaining hundreds of packages in universe that have php5 dependencies.
* While I am aware that many users use PECL/PEAR directly, we have to be careful about breaking the repositories.
I do apologize for the lack of communication on my part to this point. I have been really trying to get to a point where I can make a more educated statement about the feasibility of 5) and have made a lot of headway at this point. I will strive to keep the community more up-to-date on my progress going forward.