| Summary: | dev-lang/php-7.0.15 stable request | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tomáš Mózes <hydrapolic> |
| Component: | Stabilization | Assignee: | PHP Bugs <php-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | axiator, bug, flyser42, hanno, leho, pastas4, simon, tsmksubc, zlogene |
| Priority: | Normal | Keywords: | STABLEREQ |
| Version: | unspecified | Flags: | stable-bot:
sanity-check+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: |
=dev-lang/php-7.0.15
|
Runtime testing required: | --- |
| Bug Depends on: | 573892, 588608, 593772, 604706, 609548, 609552, 609556 | ||
| Bug Blocks: | 610078 | ||
|
Description
Tomáš Mózes
2016-02-09 11:49:04 UTC
This will need eselect-php-0.9.1, but the open security bug should take care of that. 7.0.4 was just released. 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. 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. 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. 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 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.
So what's the path to moving forward on this? (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. 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. (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. >
> 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.
Any updates? Have some php7 boxes in prod working fine. (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. No stable PHP7 on gentoo yet? Any expected time frame? 7.1 RC6 is already out... 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 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? 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? (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. Well, seems this will never be stable marked? ;-) Setting target version. Please do final checks before I cc arches Arches, Please test and mark stable Target keywords dev-lang/php-7.0.15 alpha amd64 arm hppa ia64 ppc ppc64 sparc x86 7.0.15 is not anymore in tree An automated check of this bug failed - the following atom is unknown: dev-lang/php-7.0.16 Please verify the atom list. 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? (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. An automated check of this bug succeeded - the previous repoman errors are now resolved. amd64 stable Stable for HPPA. Stable on alpha. x86 stable arm ppc64 stable. ppc stable. sparc stable ia64 stable. Closing. |
