Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 574238 - dev-lang/php-7.0.15 stable request
Summary: dev-lang/php-7.0.15 stable request
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Stabilization (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: PHP Bugs
URL:
Whiteboard:
Keywords: STABLEREQ
Depends on: 573892 588608 593772 604706 609548 609552 609556
Blocks: 610078
  Show dependency tree
 
Reported: 2016-02-09 11:49 UTC by Tomáš Mózes
Modified: 2017-03-11 17:09 UTC (History)
9 users (show)

See Also:
Package list:
=dev-lang/php-7.0.15
Runtime testing required: ---
stable-bot: sanity-check+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomáš Mózes 2016-02-09 11:49:04 UTC
8 RC versions plus 3 normal releases should be ok to go stable. I'm actually using it in production.
Comment 1 Michael Orlitzky gentoo-dev 2016-02-10 13:42:27 UTC
This will need eselect-php-0.9.1, but the open security bug should take care of that.
Comment 2 Leho Kraav (:macmaN @lkraav) 2016-03-03 19:51:48 UTC
7.0.4 was just released.
Comment 3 Tomáš Mózes 2016-04-07 08:51:15 UTC
The only bug we hit with 7.0.4 was the opcode clearing. Sometimes it fails to clear the cache (by calling opcache_reset()). Apart from that, it works very well - serving millions of requests a day.
Comment 4 Michael Orlitzky gentoo-dev 2016-04-07 12:25:39 UTC
We can stabilize this now, but since the 7.x slot was never stable, we can't do it as part of a security bug. That means it has to spend the usual 30 days in ~arch, which in turn means we need to go 30 days without a 7.x security release replacing 7.0.5.

I set a reminder for myself to stabilize it if there haven't been any problems on May 5th.
Comment 5 Tomáš Mózes 2016-04-07 12:50:08 UTC
Thanks Michael, however by checking the NEWS for 7.0.6 it seems it will be a security bump also. I suppose it will be released in few weeks time. So it's a magical circle :) 

But better to start in 30 days then never.
Comment 6 Brian Evans Gentoo Infrastructure gentoo-dev 2016-04-07 13:00:47 UTC
When 7.0 goes stable, we might want to wrap in pecl-apcu, pecl-apcu_bc, pecl-imagick, pecl-mailparse and xdebug to provide 7.0 compatible extensions which are currently marked stable.

There should be several PEAR modules that should also be reviewed as well.
I'll have to work on a list of those version
Comment 7 Michael Orlitzky gentoo-dev 2016-05-13 19:55:48 UTC
I'll reply here instead of on the security bug so it doesn't email a million people.

(In reply to Tomáš Mózes)
> 
> What breakage do you mean? I also thought about stabilizing 7.0 and then the
> extensions.

If I have PHP_TARGETS="php5-6", then basically any version of pecl-apcu should work for me. But,

  mjo $ PHP_TARGETS="php5-6" ACCEPT_KEYWORDS="~amd64" emerge -pv1 pecl-apcu

  These are the packages that would be merged, in order:

  Calculating dependencies \

  !!! Problem resolving dependencies for dev-php/pecl-apcu
  ... done!

  !!! The ebuild selected to satisfy "pecl-apcu" has unmet requirements.
  - dev-php/pecl-apcu-5.1.2::gentoo USE="lock_pthreadrw mmap -lock_pthreadmutex 
  -lock_semaphore -lock_spinlock" PHP_TARGETS="-php7-0"

    The following REQUIRED_USE flag constraints are unsatisfied:
      php_targets_php7-0

    The above constraints are a subset of the following complete expression:
      exactly-one-of ( lock_pthreadmutex lock_pthreadrw lock_spinlock 
      lock_semaphore ) any-of ( php_targets_php7-0 )

As soon as we mark something like pecl-apcu stable, that's going to start hitting stable users unless they can add php7-0 to PHP_TARGETS. But then, if those users are using any *other* extensions,

  $ PHP_TARGETS="php5-6 php7-0" emerge -pv1 pecl-apcu
  
  These are the packages that would be merged, in order:

  Calculating dependencies... done!
  [ebuild  N     ] dev-php/pecl-apcu-4.0.7-r1::gentoo  USE="lock_pthreadrw mmap 
  -lock_pthreadmutex -lock_semaphore -lock_spinlock" PHP_TARGETS="php5-6 
  (-php5-4) -php5-5" 0 KiB

  Total: 1 package (1 new), Size of downloads: 0 KiB

portage will offer to install a version that doesn't support php-7.x! If you're using two or three extensions, you could wind up in a situation where half of them only work on php-5.6 and half only work on php-7.0.

We only have around 8 problematic packages like that, but I'm not sure if they can be fixed at all. Even on an ~arch system, you're stuck with only one version of pecl-apcu: either the one that works with php-5.6 or the one that works with php-7.0.

Perhaps they would work better slotted, but time is short.
Comment 8 Dirkjan Ochtman (RETIRED) gentoo-dev 2016-05-23 11:27:47 UTC
So what's the path to moving forward on this?
Comment 9 Michael Orlitzky gentoo-dev 2016-05-24 14:25:59 UTC
(In reply to Dirkjan Ochtman from comment #8)
> So what's the path to moving forward on this?

The Right Way to Do It would be to go through all of the extensions that break compatibility -- those with one 5.x version and another 7.x version -- and try to slot them so that users can switch back and forth between php-5.x and php-7.x without breaking their extensions.

But, for example, pecl-apcu installs a PHP file:

  /usr/share/php/apcu/apc.php

If we install two versions of pecl-apcu side-by-side, where should that file go so that the two copies of it don't collide? What "require" statement should users use in their code so that things don't break when switching from php-5.x to 7.x? I think it could be done by installing into ${EPREFIX}/usr/share/php[57] instead of ${EPREFIX}/usr/share/php.

Even if that works, we would have to slot all of the problematic extensions, wait 30 days, and then stabilize them all at the same time (unless the slotting somehow fixes that dependency resolution problem).

If someone has time to do all of that and test it, that would be perfect, but I've got too much other stuff going on right now. We may have to wait it out, or just stabilize everything as-is and tell people that they can't switch between php-5/7 with certain extensions installed.
Comment 10 Michael Orlitzky gentoo-dev 2016-05-24 14:48:15 UTC
I just did a quick test to assess the feasibility of slotting. I did a revision bump on pecl-apcu-5.1.2, moved it to SLOT=7, and updated the path for its PHP file to /usr/share/php7/apcu/apc.php.

Something is screwy:

  ACCEPT_KEYWORDS="~amd64" PHP_TARGETS="php5-6 php7-0" emerge -pv1 pecl-apcu

gives me,

  Calculating dependencies... done!
  [ebuild  N     ] dev-php/pecl-apcu-5.1.2-r1:7::gentoo  USE="lock_pthreadrw
  mmap -lock_pthreadmutex -lock_semaphore -lock_spinlock" PHP_TARGETS="php7-0"
  0 KiB

which totally ignores the fact that I wanted a version for php-5.6, too. Digging into php-ext-source-r2.eclass, I see that PHP_TARGETS is only used after dependency resolution, to decide where to install things.

So I'm not optimistic that this can be done right without an overhaul of PHP_TARGETS handling. I'm rewriting that eclass in bug #512184, but trying to keep the changes reasonable.

Stabilize-everything-and-apologize might be the best we can do.
Comment 11 Brian Evans Gentoo Infrastructure gentoo-dev 2016-05-24 14:56:49 UTC
(In reply to Michael Orlitzky from comment #10)
> I just did a quick test to assess the feasibility of slotting. I did a
> revision bump on pecl-apcu-5.1.2, moved it to SLOT=7, and updated the path
> for its PHP file to /usr/share/php7/apcu/apc.php.
> 
> Something is screwy:
> 
>   ACCEPT_KEYWORDS="~amd64" PHP_TARGETS="php5-6 php7-0" emerge -pv1 pecl-apcu
> 
> gives me,
> 
>   Calculating dependencies... done!
>   [ebuild  N     ] dev-php/pecl-apcu-5.1.2-r1:7::gentoo  USE="lock_pthreadrw
>   mmap -lock_pthreadmutex -lock_semaphore -lock_spinlock"
> PHP_TARGETS="php7-0"
>   0 KiB
> 
> which totally ignores the fact that I wanted a version for php-5.6, too.

Portage is not smart enough to check USE flags across SLOTs.  A user would have to specifically have multiple slots in world or have a virtual to resolve it.
Comment 12 Michael Orlitzky gentoo-dev 2016-05-24 15:22:15 UTC
> 
> Portage is not smart enough to check USE flags across SLOTs.  A user would
> have to specifically have multiple slots in world or have a virtual to
> resolve it.

That makes sense outside of the context of things like PHP_TARGETS. If I have USE=apache2 in my make.conf and I try to install emacs, portage will pick a version of emacs and then see if it has an "apache2" USE flag. It won't require a version of emacs that has that USE flag, for obvious reasons, and it won't even prefer one or try to install one in parallel with whatever version of emacs I already have because that would take forever with a lot of flags.

The python and ruby teams have worked around that somehow but their eclasses are way more involved than ours.
Comment 13 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2016-08-09 01:06:14 UTC
Any updates? Have some php7 boxes in prod working fine.
Comment 14 Michael Orlitzky gentoo-dev 2016-08-09 03:54:18 UTC
(In reply to Mikle Kolyada from comment #13)
> Any updates? Have some php7 boxes in prod working fine.

It's going slow, but we're making progress like things on the slotted extensions (thanks to Brian), and I've been trying to get rid of the PEAR installer wherever possible. We'll need PEAR-PEAR and its dependencies stable at the same time as php7 (otherwise you won't be able to emerge any PEAR-* packages), but that has its own set of problems -- like that the upgrade doesn't run smoothly if there are more PHP packages to be emerged after PEAR-PEAR in the list.

The easy things are the new versions of packages that add php7 support but don't remove it for php-5.6. Those just need to be stabilized, and we can use all the help we can get testing (or even just identifying) those. I'm fixing one or two things a week, but then we always have to wait for the fixes to go stable and I've forgotten most of the things I've fixed already.
Comment 15 A Collector 2016-11-30 18:03:33 UTC
No stable PHP7 on gentoo yet? Any expected time frame? 7.1 RC6 is already out...
Comment 16 Agostino Sarubbo gentoo-dev 2016-12-28 08:40:44 UTC
Dear Maintainer (or who is mainly involved in this stable request),

This is an auto-generated message that will move the current component to the new component Stabilization.
To ensure that the stabilization will proceed correctly, please fill the fields "Atoms to stabilize" and "Runtime testing required" as described here:
https://archives.gentoo.org/gentoo-dev/message/4b2ef0e9aa7588224b8ae799c5fe31fa
Comment 17 Dirkjan Ochtman (RETIRED) gentoo-dev 2017-01-02 15:04:38 UTC
Since active support for PHP 5.6 has now been terminated (per http://php.net/supported-versions.php), time to get the ball rolling on this bug?
Comment 18 Dainius Masiliūnas 2017-01-02 17:22:51 UTC
Given that now 7.1 is out, does it mean that 7.1 is what is going to be stabilised, with 7.0 getting skipped?
Comment 19 Michael Orlitzky gentoo-dev 2017-01-02 19:00:28 UTC
(In reply to Dainius Masiliūnas from comment #18)
> Given that now 7.1 is out, does it mean that 7.1 is what is going to be
> stabilised, with 7.0 getting skipped?

We'll still stabilize php-7.0 first. Otherwise we would have to wait another year (and counting...) for the extension developers to release 7.1-compatible versions and then stabilize those.
Comment 20 am1 2017-02-02 10:32:11 UTC
Well, seems this will never be stable marked? ;-)
Comment 21 Brian Evans Gentoo Infrastructure gentoo-dev 2017-02-16 18:34:53 UTC
Setting target version.  Please do final checks before I cc arches
Comment 22 Brian Evans Gentoo Infrastructure gentoo-dev 2017-02-18 15:50:59 UTC
Arches, Please test and mark stable

Target keywords
dev-lang/php-7.0.15 alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
Comment 23 Agostino Sarubbo gentoo-dev 2017-02-19 13:16:20 UTC
7.0.15 is not anymore in tree
Comment 24 Stabilization helper bot gentoo-dev 2017-02-19 14:00:28 UTC
An automated check of this bug failed - the following atom is unknown:

dev-lang/php-7.0.16

Please verify the atom list.
Comment 25 Julien Papasian 2017-02-19 14:31:53 UTC
PHP 7.0.16 now depends on kernels 3.17+ due to using getrandom() instead of /dev/urandom.
There are a lot of stable kernels < 3.17 which would be incompatible with a stable PHP 7.0.16.
So I don't think 7.0.16 can be marked stable right now, maybe a patch to bring back /dev/urandom is the best? What do you think?
Meanwhile, can we get 7.0.15 back in tree?
Comment 26 Michael Orlitzky gentoo-dev 2017-02-19 15:18:31 UTC
(In reply to Julien Papasian from comment #25)
> PHP 7.0.16 now depends on kernels 3.17+ due to using getrandom() instead of
> /dev/urandom.
> There are a lot of stable kernels < 3.17 which would be incompatible with a
> stable PHP 7.0.16.
> So I don't think 7.0.16 can be marked stable right now, maybe a patch to
> bring back /dev/urandom is the best? What do you think?
> Meanwhile, can we get 7.0.15 back in tree?

I put php-7.0.15 back... the breakage with older kernels was not intentional. I'll report it upstream.

We might as well proceed with the 7.0.15 stabilization. Hopefully the getrandom() detection is fixed quickly before the next security release comes out.
Comment 27 Stabilization helper bot gentoo-dev 2017-02-19 16:01:05 UTC
An automated check of this bug succeeded - the previous repoman errors are now resolved.
Comment 28 Agostino Sarubbo gentoo-dev 2017-02-20 10:07:05 UTC
amd64 stable
Comment 29 Jeroen Roovers (RETIRED) gentoo-dev 2017-02-21 06:11:30 UTC
Stable for HPPA.
Comment 30 Tobias Klausmann (RETIRED) gentoo-dev 2017-02-22 12:33:49 UTC
Stable on alpha.
Comment 31 Agostino Sarubbo gentoo-dev 2017-02-22 16:08:16 UTC
x86 stable
Comment 32 Michael Weber (RETIRED) gentoo-dev 2017-02-22 21:24:12 UTC
arm ppc64 stable.
Comment 33 Michael Weber (RETIRED) gentoo-dev 2017-02-23 08:08:50 UTC
ppc stable.
Comment 34 Agostino Sarubbo gentoo-dev 2017-02-25 10:04:15 UTC
sparc stable
Comment 35 Agostino Sarubbo gentoo-dev 2017-03-11 17:09:20 UTC
ia64 stable. Closing.