Friday, July 16, 2010

Using multiple PHP versions

This is another "state of php in gentoo" article. Specifically, I want to talk about using SLOTs with PHP.

The current situation was created during the switch from PHP-4 to PHP-5, one of the biggest and more drastic in terms of features. PHP-5 added a full blown object oriented system, ending PHP's dubious fame as a highly advanced template engine and easing work on large code base projects. Clearly, porting your code from using PHP-4 to 5 was a tremendous effort if you wanted to take advantage of all the new and powerful features PHP-5 offered. So the then gentoo php team decided to make it possible to install PHP-4 and 5 alongside, easing migration testing and extension usage.
What they did was to slot PHP to it's major version. This is why today you're left with dev-lang/php in one slot: "5".

In a meeting on 11th April, the gentoo php team decided to halt decisions on slotting less (i.e. removing slotting) or more (i.e. on minor versions), due to manpower restrictions. This was chiefly due to our desire to get php-5.3.2 into the tree as fast as possible and we needed every minute we could contribute to gentoo at that time to this task.

Now that php-5.3.2 is in the tree and I'm slowly killing the remaining bugs left (helped, and mostly driven, by many friendly contributors, thank you!), we can focus on other areas to improve the overall quality of gentoo's PHP offers.

So slotting became an issue once again.

In an informal meeting, we agreed that removing slotting was the easiest solution, but not the best. While slotting to minor versions increases ebuild complexity and comes with it's own problems (you need a way to select the "active" PHP installation to run for the apache module, for example), the advantages in migration testing and also for shared hosting providers, who want to offer more than one PHP version, trumped the relatively low cost of slotting.

Here's a short pro-contra overview of minor version slotting I came up with:

  • test your code against the most current PHP version on the same machine

  • provide your customers the PHP they want


  • need to remove slots you don't need (or they'll take up hard disk space)

  • increased complexity in configuration

That's pretty short and I'm sure you can come up with more benefits and disadvantages. Do let me know in the comments!

I'm still somewhat disappointed with the lack of "end-user" benefits in this move. If you just want to run that cool webservice your friend has been telling you about, you'll emerge php and will receive slot updates instead of the normal ones thereafter. You regularly want to run emerge --depclean, so you don't keep around PHP slots you no longer need (thanks to darkside for helping me with this one).

Another hurdle will be that we require you to "enable" the PHP version you want via eselect to benefit from the slotting. This affects for what PHP version your PHP extensions like apc or suhosin will get compiled (each minor version has a different ABI, so for each SLOT you need a special build). We're trying to make it so that not "enabling" anything will guess the correct PHP version (probably your highest slot), but that's not sure right now. You will also use eselect to switch from one php apache module to another.

Speaking of apache modules, I've another proposal: currently, Gentoo supports a highly experimental feature called concurrentmodphp. It's a USE flag for dev-lang/php and enables you to run multiple versions of php in the same apache. Usually, this results in a symbol name clash of the php modules you try to load, but with this USE flag enabled, it should work. That said, I never used it, did not test it and upstream will tell you to rebuild without it if you do and run into problems. It's in no way supported neither by Apache or PHP. What is supported is running multiple versions of whatever you like via cgi (fpm, for that matter). So if you want that functionality, you can get it anyway, without causing maintenance problems for the team.

So here's the proposal: I will drop the concurrentmodphp functionality starting in August, if nobody objects with a technical argument on why to keep it. I'd like to hear cases where concurrentmodphp solves a problem fpm can't handle.

Anyway, if you want to help with the slotting efforts, please visit #gentoo-php on freenode, tell us to pull your ideas from your git repository (you can clone your local copy off of our slotting branch) or open bugs explaining why such and such change in said branch won't work, kills kittens or is otherwise undesirable. As always: comments welcome!


  1. Mike Thompson17 July, 2010 05:40

    Wow. Some observations re. slots: the transition from PHP 4 to 5 was like night and day. Running with multiple slots would be appealing for that transition. I'm glad to see PHP 4 gone.

    The minor versions of PHP so far--0, 1, and 2--have been pretty incremental in relation to one another. I've appreciated the new features and the bug fixes, but I don't know that any of them would merit being in its own slot.

    PHP 5.3 is another matter. Most of the really nifty features that were to be in v6 have been moved into PHP 5.3; 5.3 really ought to be a major version. This ought to be in a different slot from the earlier v5 revisions. A slot for 5.3 would make it easier to get testing.

    Now is a matter of being careful what we ask for. I am less than optimistic that eselect would do a completely good job in switching everything over. Sure, switching CLI and CGI versions would work all right (I use a lot of PHP from the Bash prompt), but I sure think it would be tricky to get mod_php to switch reliably among PHP versions--even if you had to restart Apache each time you wanted to switch. It would seem that trying to run the two verions concurrently in Apache would be very complicated and asking for trouble. At work we're having some odd issues with APC--I sure would not want to insert PHP slotting into that mix!

    Switching over to the cgi-bin version would mean altering a lot of URL's. Most people use mod_php.

    So, as much as I lot slots, and as much as I want to be able to try out 5.3, and as much as I think it would merit a slot separate from the earlier v5 revisions, I think we're probably better off using virtual machines to try out PHP 5.3. Sigh. You seem to have a wonderful effort outlined to implement this new slot, but I don't think it would be worth the effort.

  2. Thanks for taking the time to answer at such length.

    What issues do you see switching between mod_php versions?
    It's an early alpha, so I didn't include it in the post, but Ole has been working on an eselect module you can take a look on:

    To me, switching mod_php versions is just symlinking in the right shared library object (restarting apache would probably be nice). But maybe I missed something.

  3. Mike Thompson17 July, 2010 22:42

    I just smell the possibility of incompatabilities. While it works out (I would hope!) that v5.2.x and v5.3.2 have the same dependencies (apache, libpcre, libxml2, etc), I am much more concerned about things which have PHP as a dependency and might be particular about ABI's: apc, eacellerator, magickwand, etc. Maybe you could switch a symlink, but I'd think you might confuse packages that depend on PHP.

    And for what benefit and at what cost? If my experience in the 5.2-to-5.3 switch is anything like any of the earlier switches between PHP versions, I'll be delighted with the change and won't look back. (I wish I could say the same about a lot of other packages! Updating Python versions is positively hateful.)

    So if you put in the work to make Apache's hook to mod_php switch according to a symlink, that means we'll be stuck with the cumulative overhead of dereferencing that symlink at every execution of mod_php. Besides that, I'd like to be able to test v5.3 in a clean environment, knowing that any breakage I see is due to the change in version, not the artifacts of workarounds to handle PHP slotting.

    (Interesting note about the dependencies: I see that 5.3.2 no longer depends on libxslt. Does that mean we'll get XSLT 2 support without having to wait for the Gnome project to bring libxslt into the modern age?)

  4. Regarding the extensions, you will be able to select which PHP versions those will be built against. If you install apc with php-5.2 and php-5.3 "enabled" via eselect, we will compile it for php-5.2 and php-5.3. The right one should be loaded along with your php. So I don't think that's an issue.

    I'm investigating the performance cost of putting mod_php through a symlink. I honestly haven't thought about that, but for large scale deployment this could be an issue.

    On the xslt issue I'm afraid I have bad news: the xsl use flag still requires libxslt.

  5. Just to follow up on the symlink issue: the cost should be pretty much zero as the OS should cache the real path and you only need the symlink during server startup anyway. Either I'm missing something here, or symlinking should not be considered a blocker for slotting.