It's Gentoo policy to have a normal testing period of approximately 30 days. The period can be shortened or omitted if there are security problems in a current stable version. This is what's happening in the transition from php-5.2.13 to 5.2.14 right now. I intentionally migrated 5.2.14 from the overlay a few days after 5.3.3, so we could test-drive the new eblits backed system with 5.2.14 that makes maintaining PHP so much easier. While all eblits originally were designed for use in 5.3.2, I only needed to update one eblit to accommodate 5.2.14.
But there was another change with 5.2.14 that will enable me to fix bug #310383 once php-5.2.14 is stable on all architectures: 5.2.14 finally makes use of EAPI2. It heavily uses USE dependencies, and also, by popular request, includes USE defaults. This feature auto-selects USE flags if you don't disable them via /etc/portage/package.use. By default, you're now getting the same PHP features you'd get by downloading the source and just running
./configure
.The change to USE defaults also obsoletes settings certain USE flags in the default make.conf, which is what bug #310383 is about.
There's also a downside to the heavy use of EAPI2 features: we now force certain USE flags on, if you enable a specific USE flag. This is a replacement for the manual
die
message you've probably seen once in a while. An example of this is USE="truetype"
, which needs the gd (or gd-external) USE flag on. This currently results in two kinds of error messages, a nice one and a very confusing one. Observe (sorry about the wrapping here):
terra mabi # USE="readline libedit" emerge -1 php
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-libs/libedit-20090923.3.0 456 kB
[ebuild R ] dev-lang/php-5.3.3-r1 USE="libedit* readline" 0 kB
Total: 2 packages (1 new, 1 reinstall), Size of downloads: 456 kB
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-lang/php:5
('installed', '/', 'dev-lang/php-5.3.3-r1', 'nomerge') pulled in by
=dev-lang/php-5.3.3-r1[-libedit] required by ('ebuild', '/', 'dev-lang/php-5.3.3-r1', 'merge')
(and 1 more)
('ebuild', '/', 'dev-lang/php-5.3.3-r1', 'merge') pulled in by
php
Explanation:
New USE for 'dev-lang/php:5' are incorrectly set. In order to solve
this, adjust USE to satisfy '=dev-lang/php-5.3.3-r1[-libedit]'.
While I find the fact that portage is complaining about a "slot" problem misleading, it gives a nice and clear explanation about what to do to recover. Compare to this:
terra mabi # USE="sharedext sharedmem threads" emerge =dev-lang/php-5.2.14
These are the packages that would be merged, in order:
Calculating dependencies... done!
emerge: there are no ebuilds built with USE flags to satisfy "=dev-lang/php-5.2.14[-threads]".
!!! One of the following packages is required to complete your request:
- dev-lang/php-5.2.14 (Change USE: -threads)
(dependency required by "dev-lang/php-5.2.14" [ebuild])
(dependency required by "=dev-lang/php-5.2.14" [argument])
Duh! I've no clue about the root issue by looking at the error message. Turns out
USE="sharedmem"
clashes with USE="threads"
, but you can only discover this by looking at the ebuild. I'm currently working out how to get you a more informative message.That's the news for today. Stay tuned while we work out the details about slotting PHP to minor versions (certainly the topic of one of the next posts), which we hope to have out before PHP gets a 5.4 version.
It seems that 5.2.14 breaks spawn-fcgi integration. I have upgraded from 5.2.13 to 5.2.14 today and after that spawn-fcgi refuses to start. I'm still investigating the problem, and will file a bug if necessary.
ReplyDeleteYes, thanks. Given the enormous amount of ways you can use PHP, I can't test them all. So any help appreciated.
ReplyDeleteCh00k: I added a workaround to Gentoo bug 332257
ReplyDelete"EXTRA_ECONF="--enable-cgi --enable-fastcgi" emerge -av1 php"
Jeremy: Thanks for the tip :) However, I have filed the bug 332337 before I read your comment here. To my understanding, this is a major flaw and should be fixed, and 5.2.14 should be masked back for the time being.
ReplyDeleteYeah, again, I'm sorry for this oversight. 5.2.14 should be fixed now. I'm not in favor of aborting the stable process, as this release fixes quite a bunch of security bugs.
ReplyDelete