Update to php 7.0

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1522422/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

Status changed to 'Confirmed' because the bug affects multiple users.

Nah, php7 is not a revolution. php5 over php4 broke API too much, but php7 is much more close to php5.6 than php3 to php4 or php4 to php5 ever was.

And php5.6 follow the same support pattern as all php 5.x versions before: http://php.net/supported-versions.php

Thus I don't think Debian would ever release with two versions of PHP -> stretch will have only 7.x (most probably 7.1) and I really advice Ubuntu to do the same.

If you need to run 5.6, you can do that will older Ubuntu release.

I don't agree, PHP 7 is up to twice as fast as PHP 5.6. If it is not a revolution, why a lot of big sites use HHVM and not PHP 5.6? PHP 7 and HHVM performance are similar, so please add PHP7 to repository.

Just a small clarification, the advantages that the big sites have obtained using HHVM are ONLY related to performance. Do not insert PHP7 in repository is a big mistake. Certainly you can always compile it, but why follow this road? What real benefits?

The performace improvement is nice, but "revolution" would mean a lot of broken code, and this is not what happens with PHP 7.0. The amount of breakage is not that big to justify the amount of work to also support PHP 5.6.

I think completely different from you. I think the fact that there is not 'broken code' does not justify the non-inclusion.

You are just repeating the same story that I've heard with every minor version. I still hear some broken obsolete code requires PHP 5.3. The major version bump is not as severe as with python2->python3, so there's a need to put a stake into the ground somewhere.

Also "think" is different from putting your money where you mouth is. Maintaining several versions of PHP requires a substantial amount of work. And the amount of work and support required is much higher when you release multiple versions of PHP as part of stable release than let's say supporting those versions in outside repositories (like my ppa:ondrej/php*).

Ultimately this would be a Canonical people's decision, but I strongly advice against having a multiple versions of PHPs as part of stable Ubuntu release.

I did not know that each time was released a minor version of PHP at the same time was released on the market a product as HHVM which is up to twice as fast as PHP 5.6 without changing one line of code. However do not be surprised if people will go to HHVM, if canonical decides not to support PHP 7. If this makes you happy, I hope for you that will happen.

I also wish to see PHP 7 in the next LTS. It was released somewhat too late to replace 5.6 so the next best thing is a new package. Wait. You say almost nothing has changed, so why not ditch 5.6? That sounds good too.

It's really all about the speed of migration. Switching to PHP 7 as fast as possible is important for several reasons. Going to PHP 7 on productions servers would decrease running costs substantially. Especially on big projects like the one I'm working on. I'm also a huge fan of the new syntax and generally the updates to the language.

The thing is our servers run on Ubuntu LTS without any PPAs for maximum stability. If it's confirmed Ubuntu 16.04 LTS is not having PHP 7 the migrations move from being 5 months away to 2,5 years away. It's sad to even think about.

Ondřej, thanks for your work on your repos!!
Just to clarify: As of today, we don't know whether PHP 7 will make it in 16.04, correct? What does it depend on? Are there any links to discussions about that? I did not find any ...

Phillip, that's a question for @rbasak and ultimately for Canonical whether they allocate enough time to make it happen.

Thanks for the quick answer. Let's see what we can do about that :-)

For what it's worth, I would really like to see PHP7 in Ubuntu 16.04. Is there anything I could do to help it to happen?

I wouldn't exactly call PHP7 a revolution - it's faster, and it has some nice features (particularly valuable for me are return type hinting and scalar type hinting). I've upgraded a few applications from PHP5.3 to PHP7.0 without any changes to the code. I did have to change configuration like where the PHP 7.0 FPM is located, but that was it, and the speed improvement was noticeable.

I feel like vinc-q and Ondrej actually agree with each other but don't realize it...

For what it's worth, I agree that Ubuntu should have PHP7, but we don't need two PHP packages. There aren't enough BC breaks to warrant it. Like Ondrej said, you can stick to older Ubuntu releases or build from source if you need <7.

Here's a thought: I don't know anyone running Ubuntu servers who's using the stock PHP because it's usually too old. People either use Ondrejs PPAs, compile themselves or use some other vendor (i.e. Plesk provided packages).

PHP 5.6 support ends August 2017. That's 9 months of backporting security fixes. PHP 7.0 is supported until December 2018.

If you ask me, this is a no-brainer. Ship the latest available version with every LTS. @Ondrej, thanks for your awesome work!

Still using Ubuntu 12.04 LTS with php 5.3.10 ...
at work, the policy is to change distribution each 4 years, a few months after the LTS is out, with no additional ppas.

next upgrade is for 16.04 LTS aproximatly in june 2016!
the next one will be for 20.04 LTS ... aproximatly in june 2020!

So, I would really like to have php7 which is 2 times faster than php5, otherwise I will be stick with php5 until mid 2020....

Please add a php7 branch in the core 16.04 distribution.

It has been added:

http://packages.ubuntu.com/xenial/php/php7.0

We haven't committed to anything yet. The schedule is tight. Whatever we ship we will need to support for 5 years, so it cannot be half done.

We are pretty certain that we don't want to ship both 5.6 and 7.0, so we expect to remove one or the other before release. Based on my current understanding I would like us to ship 7.0 in 16.04, but the transition needs to be completed first. For 7.0 to make 16.04 it needs to have replaced all the functions that 5.6 currently performs for us (reverse dependencies etc) and replace 5.6 in main. If this doesn't happen by feature freeze (18 Feb), we expect to remove 7.0 from universe, and 16.04 will ship with 5.6 only.

We can continue to use this bug to keep everyone updated. If there are any blocking issues then we'll mention them here. I will try to make sure that anyone interested in making this happen has the opportunity to volunteer to fix any blocking issues in time.

Thanks for the detailed response. I'm sure that you've seen that there is a wide interest to get PHP 7 in, but I can certainly understand your reasoning. Please let us know if there is anything we can do to help make it happen!

Superlative wording by original submitter, although enthusiastic, is not accurate.

Comment #6 by Ondřej is an accurate assessment of the situation.

Comment #16 Matthias Niessis accurate risk assessment for Canonical (9+ months of backporting if they go with 5.6...)

One thing is certain though, Ondřej and his PPA is a PHP hero. :)

@racb and rest:

The main blocker is all the rdeps that depend on php5-<something>. There are two approaches we could take:

1) patch all the sources to depend on php-<something>

2) prepare src:php5 that just depend 1:1 on src:php7.0

well, there's third option:

3) do as much 1) and then finish with 2)

I have prepared 2) here: http://anonscm.debian.org/cgit/pkg-php/php5.git/

Re 1) the new pkg-php-tools and naming needs decision and a quite lot of work:
http://lists.alioth.debian.org/pipermail/pkg-php-pecl/Week-of-Mon-20160104/000677.html

This has to be solved by PEAR maintainers with help from anybody who has time to help (that's not me).

Cheers,
Ondrej

Thanks Ondřej, this is helpful.

On Fri, Jan 08, 2016 at 10:45:45AM -0000, Ondřej Surý wrote:
> 1) patch all the sources to depend on php-<something>

In Ubuntu we don't have specific maintainers for packages, instead teams
that work towards goals. So unlike Debian where you'd need to mass file
a bug, give maintainers a chance to respond, then perhaps upload delayed
NMUs etc, in Ubuntu the method is for one developer to just mass upload
a change like this as necessary. So the actual doing of it doesn't
concern me, but there is a risk in having to deal with any failures that
might be the problem for our schedule.

However we do want to end up in sync with Debian in the end, of course,
so we don't want to do something one way if Debian will eventually do it
another.

> 2) prepare src:php5 that just depend 1:1 on src:php7.0

Or we could drop src:php5 and provide additional transitional packages
in src:php7.0 instead, which would appear to be the same thing from a
binary package perspective.

Either way we could do this, but it seems wrong and hacky to me, except
temporarily and where users might install these directly and therefore
need a transitional package.

> well, there's third option:
>
> 3) do as much 1) and then finish with 2)

If we do 2) then that's only temporary anyway, presumably, since we'll
want to drop all transitional packages in a future release both in
Debian and Ubuntu?

Given the schedule we probably want to take the path of least resistance
though. I certainly don't want to do something you don't want to support
in Debian.

> Re 1) the new pkg-php-tools and naming needs decision and a quite lot of work:
> http://lists.alioth.debian.org/pipermail/pkg-php-pecl/Week-of-Mon-20160104/000677.html
>
> This has to be solved by PEAR maintainers with help from anybody who has
> time to help (that's not me).

This worries me a bit more. Do we risk breaking PEAR/PECL users if we
commit to PHP 7.0 in 16.04 and then find we don't have this ready in
time?

> This worries me a bit more. Do we risk breaking PEAR/PECL users if we
> commit to PHP 7.0 in 16.04 and then find we don't have this ready in
> time?

PECL seems to be mostly fine although some PECL packages won't be converted at all and some need a code from some upstream git branch.

PEAR is hard to say - that's probably individual. I've seen report about broken Cacti with PHP 7 just today, so it needs some effort to test at least major packages.

The timing is very tight, but I think it's doable if you put enough effort into it and do some SRUs later to move the PECL modules from git branch to release code. This might be good to prenegotiate with release/core team.

Both choices are horrible due timing, but fixing bugs in PHP 5.6 long after it's security support has ended is a nightmare because PHP 7.0 has diverted too much from PHP 5.6 code.

Fixing bugs as they appear in PHP 7.0 and dependent packages should be much much easier because it will be up-to-date code. It might need relaxing SRU policy a bit, but it will pay of in invested time (and money) long term.

Also I would say that people expect to find PHP 7 in next LTS and the sheer effect of disappointment might lead to distro-switch (although my PPAs could come to save a day in such case, there are some people who won't use PPAs in production no matter what).

In the end, this should not be just a technical decision, because the impact of either choice are also not technical.

There's no point in shipping both PHP5.6 and 7 given they're mostly backwards compatible. PHP7 on 16.04; those who want PHP5 could either PPA or remain on earlier versions of ubuntu.

Never mind then!

https://twitter.com/zeevs/status/687241123467767808

...

After studying php-fpm architecture, I think the best handling is to support php7 as php7-fpm. Instead of using mod_php, Apache will have to connect to php7 through mod_proxy_fcgi. With proper setting, one can have both php5-fpm and php7-fpm run in parallel. The Apache server can then support both PHP version at the same time.

OK, OK. I was here because I didn't find php7-fpm in the current repository. And I really want to use it.

I've manually compiled it for my use, but I want an official package that will automatically have updates and patches.

php7.0-fpm is in Xenial/universe.

I am very interested in making this happen and in also making sure that the PHP community is able to respond quickly and to help if there's anything that can be done to make this happen. As has been discussed, most PECL packages are ready for PHP 7, PEAR is now much less widely used in PHP since most projects will bring userland dependencies in via Composer. I notice however that the php-pear package is still depending on PHP 5, so I can't say how well either PEAR or PECL will work with the PHP 7 packages that have already been worked on (and which look awesome, thanks!)

Thanks to everyone contributing to this, I am watching the issue and will be happy to help in practical terms in any way that needs helping.

Not my intention to just do a +1 here, but I'd love to have PHP 7 in Ubuntu 16.04. Sure,
Ondřejs PPA would work, but as mentioned earlier - I think it would disappoint many users if PHP 7 didn't make it into 16.04. I really hope you make it!

Thanks for an awesome OS, and thank you Ondřej for your work making the internet faster.

To stop further disinformation most of PHP 7 is already packaged for xenial:

http://packages.ubuntu.com/search?keywords=php7&searchon=names&suite=xenial&section=all

So let's concentrate on whats missing. I think we're missing some extensions so far like:

php7.0-mysqlnd (neither in Ondřej's PPA or Ubuntu!)
imagemagick (in Ondřej's PPA but Ubuntu has only php5-imagick)
graphicsmagick (neither in Ondřej's PPA or Ubuntu!)

@Ondřej can you give a little overview regarding missing extension?

BTW I am willing to help with the packaging :)

@bhat3 phpX.Y-mysql is already compiled with mysqlnd; php-imagick is the package you seek. graphicsmagick was not yet asked for by anybody, so I haven't touched it.

@Ondřej Nice to know, but for clarification:

mysqlnd: that means we're using mysqlnd now by default and there is only one package now?

imagick: php5-imagick is also the package for PHP 7?

gmagick: Here, asking for it ;) No serious i can really reduce the load on servers and with the 2.0.0 extension release it's ready for 7.0 (https://pecl.php.net/package/gmagick) How can i help here?

> mysqlnd: that means we're using mysqlnd now by default and there is only one package now?

Yes

> imagick: php5-imagick is also the package for PHP 7?

No, I said `php-imagick`, so it's php-imagick and not php5-imagick.

> gmagick: Here, asking for it ;) No serious i can really reduce the load on servers and with the 2.0.0 extension release it's ready for 7.0 (https://pecl.php.net/package/gmagick) How can i help here?

Please fill an issue here: https://github.com/oerdnj/deb.sury.org/issues I'll look into it when I have some time.

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://help.ubuntu.com/community/Repositories/Ubuntu, that means that PHP5.6 is "Officially supported software" while PHP7.0 is "Community maintained software, i.e. not officially supported software".

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://php.net/supported-versions.php].
    - 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://php.net/supported-vers...

@Nish: Big thanks for sharing the thoughts of the server team and that you take this issue serious :) Running quite a lot web servers with PHP on Ubuntu LTS and RHEL in prodution, i like give you some short feedback on the mentioned options:

1 & 4: are a no go if Ubuntu Server wants to stay as relevant as it is now in the web server OS market. Although it would probably bring a big boost to Raphaël Hertzog's LTS efforts ;)

2: Is what makes users really happy. It will definitely strengthen Ubuntu's role in the PHP market with more work for Canonical.

3 & 5: While i can fully understand the reasons, both will dissatisfy a lot of people. Given the reduced load impact of PHP 7.0 in data centers and the huge install base of widely used PHP 5.* web apps.

So option 2 is the bravest option for Canonical, but will give you the most user satisfaction. Given that the packaging work by Ondřej and others made this dual stack option possible and AFAIK didn't happen with Canonical involved, you could just keep "standing on the shoulders of giants" as maintenance would be mainly communication, syncing and merging with Debian or out sourcing to Ondřej ;). And for just sticking to that, you should really take feedback from the PHP and security teams at Debian :)

BTW i would love to see option 2 happening, as i am still so happy about the other brave move Canonical made with promoting Nginx to main for trusty. I replaced Apache in so many production environments :)

> - No clear (obviously safe?) path for users upgrading from a PHP 5 base (Trusty or Wily) to PHP 7 base.

If you can pull this http://anonscm.debian.org/cgit/pkg-php/php.git/commit/?h=master-jessie&id=23e81c46bb4978596efe58a23070eb75dd3d5380 via SRU you might be able to keep src:php5 from trusty on top of xenial (given there are no conflicts in the libraries.

> Re: 7.0 security support ends in 2018

I expect the changes between 7.0 and 7.1 (and 7.2) much less intrusive than changes between 5.6 and 7.x branch, so the security team will have easier job maintaining 7.0 past 2018. (Same with PHP 5.4 <- we pull security changes from PHP 5.5 for the moment.)

> Re: xdebug segfaults

I just updated xdebug to rc4 today - retry with that. I had some users reporting the segfaults in rc3 but fixed in git.

> > Re: xdebug segfaults
>
> I just updated xdebug to rc4 today - retry with that. I had some users reporting the segfaults in rc3 but fixed in git.

Yeah, I actually built RC4 myself last night to test and it didn't seem to make any difference. Note that I'm using the pkg-php-tools from http://anonscm.debian.org/cgit/pkg-php/pkg-php-tools.git/log/?h=master-7.0, but I don't think the issue should be there, but in xdebug itself.

Here's the debug I've gotten so far. The segfault is line 1150 in xdebug_stack.c:

                } else if (edata && edata->prev_execute_data && edata->prev_execute_data->opline && edata->prev_execute_data->opline->opcode == ZEND_INCLUDE_OR_EVAL) {

I added some manual debugging (as I learn how to build non-optimized versions of packages) and got:

edata = 0x7f5b23214030
edata = 0x7f5b23214220
edata->prev_execute_data = 0x7f5b232141b0
edata = 0x7f5b23214380
edata->prev_execute_data = 0x7f5b23214310
edata = 0x7f5b23214850
edata->prev_execute_data = 0x7f5b232147e0
edata->prev_execute_data->opline = 0x7f5b2328d500
Usage:
    pkgtools COMMAND

Options:
    --help: print help
    -h: print help
    --verbose: increase verbosity
    -v: increase verbosity
    --sourcedirectory: set source directory
    -D: set source directory

Commands:
  : Without arguments: print help
edata = 0x7f5b23215000
edata->prev_execute_data = 0x7f5b23214f90
edata->prev_execute_data->opline = 0x3
Segmentation fault (core dumped)

Seems like prev_execute_data is corrupt?

On 26 Jan 2016 5:25 p.m., "Nish Aravamudan" <email address hidden>
wrote:
> - Users who do wish to have PHP 5, must use a PPA (Ondřej's or
otherwise).

Or stick with the current LTS until they're in a position to adopt PHP 7.

At work we won't upgrade to Xenial until all our code is compatible with
PHP 7, and then if Xenial doesn't ship a supported PHP 7 I'll recommend we
switch to a distro that does, or install a supported 3rd party package like
Zend Server. I imagine there are many PHP houses that will do the same. (I
don't mean that to sound like an ultimatum, just illustrating a real world
use case.)

I appreciate all the work people are putting in to try to make this happen.

PHP Mapscript is important to me, is there anything I can do to help with
that?

Cheers,
R

--
"Racing turtles, the grapefruit is winning..."

On 26.01.2016 [19:57:31 -0000], Richard J. Turner wrote:
> On 26 Jan 2016 5:25 p.m., "Nish Aravamudan" <email address hidden>
> wrote:
> > - Users who do wish to have PHP 5, must use a PPA (Ondřej's or
> > otherwise).
>
> Or stick with the current LTS until they're in a position to adopt PHP
> 7.

Absolutely, sorry -- I should have called this out explicitly as an
option.

> At work we won't upgrade to Xenial until all our code is compatible with
> PHP 7, and then if Xenial doesn't ship a supported PHP 7 I'll recommend we
> switch to a distro that does, or install a supported 3rd party package like
> Zend Server. I imagine there are many PHP houses that will do the same. (I
> don't mean that to sound like an ultimatum, just illustrating a real world
> use case.)

This is excellent to understand, thank you for providing your input!

> PHP Mapscript is important to me, is there anything I can do to help with
> that?

I think once/if swig is updated, mapscript will too. If you can take a
look at the swig issue and help out there, that'd be great! Otherwise,
it's on my own todo list.

Maybe it's too late to throw my hat (and opinion) in, but from a hosting/hoster perspective, that's really a double-edged sword. Of course it would be splendid, if we could migrate all customers and applications to PHP7 as soon as possible. But with PHP itself increasing the support level of PHP5.6 to almost the same EOL date that PHP7 has, wouldn't it be possible to let BOTH stay in the repositories? As both now have a distinctive namespace (php5/php7) it would be incredibly helpful for us server or hosting providers, to get our customers to migrate to the new base OS (xenial) while having the possibility to select PHP5.6 or PHP7 as their web stack. With xenial only having PHP7 packages, most of our clientel will supposedly need to stay on trusty or - even worse - has to upgrade to trusty from precise, because (as sad as that is) there are a great many procucts out there, that don't have PHP7 compatibility right now (and don't plan to in the near future). Even worse when throwing in products like ZendGuard (*shiver*) into the mix, that don't support PHP7 yet (ergo all encrypted stuff from them won't work on PHP7/xenial for some time to come).

So having both php version lines would actually be a huge blessing for hosting/server customers and easier upgrade paths.

Jens G. said:
"there are a great many procucts out there, that don't have PHP7 compatibility right now (and don't plan to in the near future). Even worse when throwing in products like ZendGuard (*shiver*) into the mix, that don't support PHP7 yet (ergo all encrypted stuff from them won't work on PHP7/xenial for some time to come)."

You say many products..... and do not mention anything else than ZendGuard...

I always had problems with ZendGuard not supporting php releases, (or supporting them 2 years after the release is integrated in a ubuntu LTS release cf trusty...).
I also had problems with their "perpetual licence" that is not so perpetual...

So I wrote a php obfuscator for myself, that I made freely available under MIT license at https://github.com/pk-fr/yakpro-po
Perhaps you could consider using it....

php7 is a must!

@jegr Just run Ubuntu Trusty for PHP 5.x, virtualization is nowadays cheaper then dual PHP version maintenance. Or just have two sets of machines on on Trusty and second on Xenial and migrate the customers between those platforms.

The story with "foo doesn't support bar" is getting too old as I've heard it too many times. And it usually means "somebody else should carry the costs for supporting this really old unmaintained piece of software for us".

> So I wrote a php obfuscator for myself, that I made freely available under MIT license at https://github.com/pk-fr/yakpro-po
> Perhaps you could consider using it....

We are a hosting and service company and only administer, consult and service our customers. Their web agencies or programmers bring the requirements and we have to deal with it.

> php7 is a must!

That is your stand and I personally find it very valid. But we are not talking any OSS projects, but (sometimes) closed source software like various shops or modules etc. And those companies won't simply change just because we want them too. And our customers (as hosting company) have invested quite a hefty sum into their shops, so they, too, won't just switch to another software including external connections, payment etc. etc. just because PHP made a new release.

It's extremely frustrating on our side as I see the same thing as the trusty release will be hitting us again. A great new OS that we simply can't use for many customers, as they rely on older versions, that won't switch for months (or years). And PHP plays a great deal in that stack that is used.

I'm not sure if this bug is the appropriate place to discuss this, but can't your customers who require an older version of PHP simply stay on 14.04LTS? It is supported until 2019. Isn't that the whole point of LTS releases?

@ondrej I agree to some degree, as it would be reasonable to run xenial under the hood, not only because of the base OS but the rest of the web stack, too.

And as already stated, as PHP5.6/7 are supported from PHP to almost the same EOL time now, so it's not about "please support old unmaintained software for us" ;) As Trusty includes PHP 5.5, that would be more of a problem as to have 5.6 & 7 as options on a new platform with support until 2021. Installing trusty mid- to end-2016 feels the same as the precise/trusty thingy we had to endure the last 4 years.

That's why I'm just throwing that idea into the room. I know what we have to do otherwise, but just wanted to have a shot at perhaps brighten up the situation :)

@jstsch I'm not trying to start a specific discussion about customers or software but merely was pointing out that service providers or hosters would actually profit from both package branches staying available instead dropping one of them after freeze. And as both EOL dates are nearly the same it isn't like one of them is a support nightmare and unsupported upstream in near future.

Of course customers on trusty can stay on that. But we'll alert precise customers shortly about options for upgrades. And if xenial stays on php7 those are most likely to become trusty boxes as well, what I personally find a rather unsatisfactory solution but perhaps is inevitable.

Jens G. is right. In fact, the PHP community has extended the 5.6 support: https://wiki.php.net/rfc/php56timeline

@jegr The folks who already have PHP code compatible with PHP 5.6 shouldn't have any problems updating to PHP 7.0. I would worry more about the upgrade from PHP 5.3 in precise to PHP 5.5 in trusty.

If the customers could upgrade their code to PHP 5.6, they might as well jump directly to PHP 7.0. The most intrusive changes that broke software has happened between PHP 5.3 and PHP 5.4.

@jstsch you need OpenSSL 1.0.2 for ALPN support (needed for proper HTTP/2 negotiation), not included in Ubuntu 14.04. Why not give the possibility to use http/2 with php5.6, since it is still supported and active?

@vinc-q @jegr An upstream unmaintained code would be total no-go, but still having two versions of PHP in the main is a quite big burden for Ubuntu folks.

I could afford to run PPAs with multiple PHP versions, because I have the liberty of saying: "upstream bug, bummer" and do nothing about it if I don't have time or motivation to fix it. That's the freedom Ubuntu folks don't have, so I am at their side. Just look at the PHP bug lists (both in Debian and Ubuntu).

Guys, please can you keep the noise down in here? I really appreciate the community discussion, but doing it in this bug just creates noise for the developers working on this. If you want to continue this discussion, you're welcome to do it on the ubuntu-server mailing list (https://lists.ubuntu.com/mailman/listinfo/ubuntu-server) but please try to stick to a single thread. You're not reaching the right people in this bug anyway.

@ondrej there are many features to be removed in PHP7. Of course, already deprecated , but who manages hosting has no control over the code that cannot work on PHP7.

@racb why isn't this the appropriate place to talk about the manner of this update?

This bug is whatever we (collectively, including you) want it to be. But if you want it to be a subjective discussion about the pros and cons of what Canonical should commit to supporting in main, then that's fine but the developers actually doing the work will just start to ignore bug comments (since they are not productive), start tracking their actual work in a different bug, and we'll mark this bug "Opinion" and let you carry on.

I welcome your opinion, but let's not impede development work by mixing technical progress with subjective opinionated conversation in the same bug.

> since they are not productive

By this I mean that they are not productive to landing PHP 7 in main in Ubuntu, which is the developers' direct goal for Xenial at the moment and is what the bug title currently says this bug is for. I didn't mean to imply that your comments are not productive; sorry if this came across wrong.

@racb you're right, sorry.

In response to #53, speaking for the Drupal community, I'd like to report that we have Drupal 8 passing on PHP 7. See https://www.drupal.org/node/3060/qa for details.

FYI, PHP 7.0 is in main now (7.0.4-5), and several extensions with build-dependencies from universe are in universe. We are still working on the removal of PHP5, but I think this bug can be marked fix release as we are using other bugs to track specific actions.

@colan, to clarify, I believe drupal7 does *not* support PHP7.0, is that accurate? Currently niether debian nor ubuntu have a packaged version of drupal8.

@Nish Yes Drupal 7 doesn't yet support 7.0 and as much as i like Debian packages it makes more sense to deploy Drupal with Git.

There are plans to get Drupal 7 working with PHP 7, but there are still some issues remaining. With everything that's going on with Drupal 8, I don't think folks have had a chance to jump into this too deeply just yet. For more information, see https://www.drupal.org/node/2454439.

I wouldn't focus too much on the Debian packages. In my experience, they're not used very widely (as stated above) as there are usually custom changes. So getting Drupal 7 running on PHP 7 (without the Debian packages) would be the goal here. The packages aren't even mentioned in the official installation guide, https://www.drupal.org/documentation/install/download, or on the OS-specific page: https://www.drupal.org/node/557908.

Having said that, though, I'd be curious to know if the package maintainers had any insight they could share.

@bhat3, @colan,

Thank you very much for the feedback. I just submitted a debdiff in Bug # 1544352 for drupal7 as it is in 16.04 to change the deps to PHP7. It does work, in that I can setup a very basic instance and it ... runs :) But I don't really have the bandwidth to test it further. While I understand that upstream (drupal.org) may not mention these packages, the goal is obviously for a distribution to provide a self-sufficient instance. Would either of you be able to help test that version once it lands and indicate which if any of the upstream patches are relevant? Feel free to contact me offlist if need be. Thanks!

I'm not able to help with this at the moment, but I sent an e-mail to the package maintainers letting them know. Hopefully they'll get in touch.

@nacc,

I'm really sorry to pester as you must be v. busy at this point but is there a definitive word on what's going to happen with 16.04 GA? It's only 3 weeks away and people are having to plan out what release they'll be deploying in the near future.

FWIW as a service provider, I'm squarely with @jegr : choice (as in two supported versions as is the case in beta 2) would be much preferable!

On 01.04.2016 [06:05:01 -0000], Christian Sarrasin wrote:
> @nacc,
>
> I'm really sorry to pester as you must be v. busy at this point but is
> there a definitive word on what's going to happen with 16.04 GA? It's
> only 3 weeks away and people are having to plan out what release they'll
> be deploying in the near future.

Yep, we're going to be php7.0 only, as stated prior. Sorry for the
silence, I've been heads-down updating packages and dropping ones that
are not supported -- we are down to about 95 reverse-dependencies
holding php5 in the archive; I'm hopeful to get through that list today.

> FWIW as a service provider, I'm squarely with @jegr : choice (as in two
> supported versions as is the case in beta 2) would be much preferable!

That is more the case by happenstance; php5 is in universe because to
remove it directly would have broken much of the php part of the archive
:)

Just an FYI to all, php5 has been removed from Xenial and php7.0 is the only available PHP in 16.04!

@Nish Thank you so much! Where can I donate?

@Nish You mean the only available PHP in main or did i miss something about php5.6 in universe?

On 11.04.2016 [08:53:49 -0000], bhat3 wrote:
> @Nish You mean the only available PHP in main or did i miss something
> about php5.6 in universe?

There are no PHP5 options officially provided in the repositories in
16.04, in main or universe. The issue becomes, if we have PHP5
officially in universe, whether end-users read the policies or not, it
will appear to be supported (particularly for security fixes), except it
won't be. We are slightly ahead of Debian in this migration, but they
are going down the same path in parallel.

For PHP5, end-users should stay on Trusty (or run it in a
container/VM/etc).

@Nish thanks for clarification :) I can fully understand the decision, but it's still a burden for any PHP5 project there having only a three year LTS from Ubuntu left. Just been to a Drupal Conference this weekend and for example we will probably never see Drupal 7 in production "on anything" other than trusty or in the long run CentOS/RHEL (they will support PHP5 the ultralong enterprise way).

Anyway great to have PHP 7.0 in and big thanks for all you effort. Now the whole PHP community needs to migrate to PHP7 and all data centers will be happy then running xenial :)

BTW: My personal burden is that i can't update all our trusty servers to xenial now and can't finally consolidate to systemd (having also RHEL servers). In general that means a big maintenance burden to Ubuntu admins, as you will not only start to have two production systems but also two staging and two development systems with xenial and trusty. So while PHP7 has 2x times less resource usage i will have 2x times resources spend on not being able to consolidating and combining all servers to Ubuntu 16.04 ;) ;) ;)

On 12.04.2016 [09:28:47 -0000], bhat3 wrote:
> @Nish thanks for clarification :) I can fully understand the decision,
> but it's still a burden for any PHP5 project there having only a three
> year LTS from Ubuntu left. Just been to a Drupal Conference this weekend
> and for example we will probably never see Drupal 7 in production "on
> anything" other than trusty or in the long run CentOS/RHEL (they will
> support PHP5 the ultralong enterprise way).

3 years *should* be sufficient time to move to PHP7.0 -- but that's just
my opinion (and wouldn't PHP5 be out of support by then anyways?)

Ack on Drupal 7 -- I have a test build of Drupal 8 (which does support
PHP7 at https://launchpad.net/~nacc/+archive/ubuntu/php7 if people want
to test/verify). Upstream Drupal 7 is still not passing all tests with
PHP7 last I checked, so we've left it broken for now in the archive.

> Anyway great to have PHP 7.0 in and big thanks for all you effort. Now
> the whole PHP community needs to migrate to PHP7 and all data centers
> will be happy then running xenial :)

That would be easiest :)

> BTW: My personal burden is that i can't update all our trusty servers to
> xenial now and can't finally consolidate to systemd (having also RHEL
> servers). In general that means a big maintenance burden to Ubuntu
> admins, as you will not only start to have two production systems but
> also two staging and two development systems with xenial and trusty. So
> while PHP7 has 2x times less resource usage i will have 2x times
> resources spend on not being able to consolidating and combining all
> servers to Ubuntu 16.04 ;) ;) ;)

Might I suggest (I don't know any or all of the details of your customer
requirements) investigating using lxd or adapt to provide Trusty in a
container (or if you need more specific requirements a VM?) and use port
manipulation to redirect to the host webserver? Then you should be able
to server PHP5 and PHP7 websites from the same installation, with both
being fully supported.

If I find some time this week or next, maybe I'll work on a blog post or
something that will help document such a configuration, at least as an
example. I will also see if I can find some way to document the
performance impact.

@Nish Sorry for the late reply:

> 3 years *should* be sufficient time to move to PHP7.0 -- but that's just my opinion (and wouldn't PHP5 be out of support by then anyways?)

In theory yes, but in practice not. I.e. my company just launched a Drupal 7 project last week and won't except a relaunch in the next three years. We already did Drupal 8 but it's not yet stable when you also look at all the modules.

> Upstream Drupal 7 is still not passing all tests with PHP7 last I checked, so we've left it broken for now in the archive.

You don't support PHP5 anymore so you should have deleted it from the archive. All the man power goes to the Drupal 8 ecosystem right now, so it will most probably stay a PHP5 app all along.

> If I find some time this week or next, maybe I'll work on a blog post or something that will help document such a configuration, at least as an example. I will also see if I can find some way to document the performance impact.

That sounds great and could indeed be a solution using Nginx as Reverse Proxy and the stuff in LXD as an upstream for it. But it's still a complex setup and LXD/LXC got some security problems as Matthew Garrett pointed out. Anyway i am willing to help you out on that if i can and we could do an example with Drupal 7 as best practice for upgrading to xenial. Just write me a mail and i share you my contact details.

> LXD/LXC got some security problems as Matthew Garrett pointed out.

This is irrelevant to this use case. If you're prepared to run PHP5 on your host, then running it inside a container on that host instead can leave you no worse in security terms even if you assume that containers provide no security at all.

@Robie: Fully agree on that. It was just for the record so nobody thinks this is a security enhancement like isolating PHP5 with LX* but rather a way for still migrating a server to xenial. Beside the container hype it's by nature more complex and tricky to do isolation with containers than virtualization, that's why i like that Canonical pushes LXC development as some gurus claimed since years that they can escape a LXC container and interfere with the host.

PHP7 is incompatible with many PECL extensions which are used by a LOT of websites, and are therefore VERY popular.

Any release of Ubuntu which doesn't include PHP5.6 out of the box, is going to be a non-starter in the server world. PHP7 is just too new. No one has had time to adapt all of the incredibly important and vast collection of PECL extensions to PHP7 yet. PHP7 will take years to adopt. Pushing out an Ubuntu release which is PHP7-centric is most defintely a non-starter.

@r5n Name those PECL extensions. General statements are not useful to anybody.

As a counter "general statement" - no, adopting PHP 7 will not take years, it's already happening and it's not such huge deal as PHP 4 to PHP 5 transition. Most if not all of the PHP 5.6 compatible code run just fine with PHP 7.

And as is was already stated here. If you require PHP 5.x, you can just stay with Ubuntu 14.04 LTS Trusty.

I'm co-ordinating the gophp7-ext initiative, if there are still some extensions missing, can you let me know which ones? I'm not aware of very many major extensions in pecl that don't have an update available at this point. Modern PHP 5 code will run on PHP 7 with few or no amendments - adoption for most companies will be well within the timescale of this ubuntu LTS release and the next one so the PHP 7 version is the right choice IMO.

Can I just say a big THANKS to everyone that made this happen, especially @ondrej? You and Ubuntu all rock :)

I am going to skip over the already addressed php 7 dooms 16.04LTS from "servers" outside of saying it's the only thing our managed VPS clients have been talking about for months, some even postponing projects launched on our systems until 16.04LTS was available, all because of it shipping with php 7.

"Can I just say a big THANKS to everyone that made this happen, especially @ondrej? You and Ubuntu all rock :)" - I have to second this! Amazing work, and SO very very happy it made it in 16.04LTS. Thank you from all of my staff and clients alike.

While I appreciate everyone's input, at this point, this bug is done/closed :) If you have a problem with a particular package provided by Ubuntu, please file a new bug.

Thanks!
Nish