In summary, dev-lang/php-5.3.2 will be the version to enter testing (~arch) on 20th June if nothing special happens.
Now, what's that "special" thing that shouldn't happen?
If you follow our Bugzilla, in this case Bug 312775, you will see quite some bugs attached to this tracker bug. This is where the php team collects everything that relates to getting our users PHP-5.3. The team, and I'd like to extend that to mean our non-dev heavy-duty contributors Ole Markus With and Vladimir Tsisaruk along with our very own Christian Hoffmann, has put quite some effort into testing PHP-5.3 already. Everything they and others have found is filed in a separate bug per issue and added to that tracker bug. Just take a look.
When Christian Hoffmann designed the php-5.3 ebuild, one decision was to minimize the "eclass-clutter" caused by it. Currently, every (minor-)release of PHP needs a new eclass, so the micro releases (5.2.1, 5.2.2, and so forth) won't duplicate an enormous amount of code (e.g. 734 lines in php5_2-sapi.eclass). These eclasses were specific to the dev-lang/php package and a hold-over from the earliest days of PHP in gentoo. Hoffie exchanged the eclass with the concept of eblits, used in sys-libs/glibc and sys-kernel/mips-sources. So in dev-lang/php-5.3.2, all phases like src_unpack, src_compile, etc. are literally outsourced to different files residing in files/eblits. This allows us to share common code without the need to clutter the "global" eclass space. Horray!
But as with every drastic change, bugs will show up. This is why the php-5.3 ebuilds were developed out of the view of most of our users. Nobody likes their production site to go offline because the team missed some crucial files, mistyped variables and released a general mayhem, right?
Currently, dev-lang/php-5.3.2 is package.mask'ed in the portage tree. This means that you need to enter it into your package.unmask file to install it. If you're a standard portage user
echo '=dev-lang/php-5.3.2' >> /etc/portage/package.unmaskshould do just that.
The current php-5.3.2 still needs all the testing it can get!
If you want to help, please unmask the ebuild locally as shown above and
emerge -av phpto see what it will do. Note that
pcre, spl, reflectionUSE flags are gone - their functionality is now part of the PHP core.
If you encounter a bug while using or installing php-5.3.2, please report it on our Bugzilla!
Still want to know what "special things" can prevent php-5.3.2 from being available without the manual unmasking step above? We will not unmask the package if there is a blocking bug on the above mentioned Tracker present. We want to make sure most of the tree will "just work[tm]" when you update PHP. What exactly constitutes a blocking bug is determined by impact - php update ate your system? apache crashes after php update? your application doesn't work anymore? We want to fix that before it hits more users. So please send us your bug reports!
One last special note: I lack the hardware to test PHP on the less common architectures like SPARC or PowerPC. If you own such a machine, our arch teams will be delighted to see your test report attached to Bug 321743. To test, keyword php-5.3.2 locally (use "x86" even if you're not on x86 machines!):
echo '=dev-lang/php-5.3.2 ~x86 x86' >> /etc/portage/package.keywords
and unmask it as described above. Continue to install PHP normally. Please attach the output of "emerge --info php" in any case and a full build.log in the event of a build-failure.
Thanks for reading and stay tuned for the next post where I report on the changes that will come with PHP-5.3