Stuart Herbert | Gentoo

We have some patches to apply for amd64, we need to transfer the PHP 5.1.1 ebuild into Portage, and then we believe we’ll be ready to look again at stabilising the new dev-lang/php packages. We’ll be looking to stabilise dev-lang/php-4.4.1, dev-lang/php-5.0.5, and dev-lang/php-5.1.1. We haven’t discussed whether or not we should stabilise dev-lang/php-4.3.11-r5. I’ll post an update on that when we’ve decided what to do on that.

I sometimes get asked why we don’t just drop PHP 5.0.5, and jump straight to PHP 5.1.1. The reason is that I’ve been asked by users to support PHP 5.0.5 for as long as possible, as there are production environments out there already using it. Some of the code in these environments doesn’t work with PHP 5.1.1 yet - and some of it can’t be fixed, as it’s encoded using one of the commercial encoders. As long as there are no outstanding security-related bugs, there’s no reason why we can’t support PHP 5.0.5 for now.

However, anyone relying on PHP 5.0.5 on Gentoo needs to be working on their upgrade path to PHP 5.1.x now.

I’ve added webapp-config 1.50.1 to the tree, which is a bug-fix for Lisa. Testing continues, and hopefully we’ll soon be ready to unmask the package and let it loose on all those ~arch addicts

I’ve also started work on a “Beginner’s Guide To webapp-config”. I confess I’m not really in the mood for writing right now, so it’ll take me a few drafts to find the right rhythm, but hopefully it’ll go a long way to helping users take the plunge into using webapp-config. Once that’s done, there’ll be a “Developer’s Guide” to match.

In the meantime, my original article for php|architect magazine about my plans for webapp-config is now freely available. If memory serves me correctly, the article was written just before I started to write the actual code, so a few things will be different today (the article was published back in 2003) - but it provides a good insight into the motivation behind webapp-config in the first place.

I’ve been contacted by several users, and by Dave Hall from the phpgroupware project, to let me know that the phpgroupware project is alive and well - it’s just their webserver that’s down with a hardware failure at the moment. I hope they’re able to get it up and running again soon.

I’m hoping to get the latest release, which includes the security fixes we need, into Portage very shortly.

Thanks to everyone who got in touch!

… about making Gentoo the platform of choice for <insert use here>. We’re already working hard on making Gentoo the best choice for webserving using Apache, PHP, and web-based applications.

But how well are we really doing?

Although it took a long time (it had to), with the Apache refresh we now deliver both Apache 1 and Apache 2 in a way that looks very close to what you’d expect to find if you downloaded and built Apache for yourself by hand. Experienced Linux users now have one less thing to surprise them if they choose to migrate to Gentoo. Tick in the box for that, maybe?

But, on the downside, the release caused a lot of pain for our existing users. We’ve had a range of complaints, and no matter how justified our answers are, we can’t ignore the fact that some of our users were left unhappy by the changes and the way they were rolled out. Hopefully some good will come from that, in the form of improving the way that Gentoo communicates with its users via proposals like emerge –news. But will that be enough?

PHP 5.0 has been out for well over a year now, and is about to be superceded by PHP 5.1; but there is currently no stable PHP 5 package in Portage. We’ve had a lot of complaints about this, including well-meaning offers from users to do it for us. On the surface, that doesn’t look too good. And we’ve still to unleash the sort of pain that the Apache refresh caused our users. I imagine that some of our users won’t be happy with that either.

But, on the upside, we’ve completely revamped our PHP support, both for now and for the future. We now support systems with both PHP4 and PHP5 installed at the same time - an important requirement, given upstream’s lack of planning on this topic, and PHP5’s lack of backwards-compatibility. We also support installing and upgrading extensions separately for each version of PHP. We must be doing something right, as I’ve been told that Gentoo has its users both inside Zend and amongst the PHP contributor community.

Web-based applications - now there is a constant race between the black hats who want to exploit the security holes that are always being found in the damn things, and our security and web-apps teams to get our packages patched and out to users so that they can upgrade and be covered - for now. That’s right; upgrade. Via portage. How many other leading Linux distros provide support for installing and upgrading web-based apps via the standard package manager? Exactly.

It has its faults - and they’re all my fault, as I designed and coded it - but our webapp-config tool gives Gentoo something that none of the other distros currently have. It’s very limited - but we are learning from those limitations, and that’ll show us what we need to do next. And, thanks to Gunnar Wrobel and Renat Lumpau, we now have a much faster and more reliable version written in Python, which I’m hoping will see us through the next year or so, and buy us the time we need to go away and come back with its replacement.

That’s how I think we’re doing, but I’m the wrong person to judge. I’m responsible for the direction we’ve taken on all these things for the last two years, even if others have done all the real work and fixed all my bugs. On those occasions that I’m forced to use a RedHat Linux Enterprise Server box, I really want to rip it out and replace it with Gentoo - because I think that Gentoo’s much closer to how I want a webserver to be than RedHat ever will be.

But what do you want next?

I’d love to hear from our users on how we’re doing. I’ve created this thread in the Gentoo Forums for you to post your views on how we’re doing, and where we should be going next. I hope we get to hear all sides - those who are unhappy as well as those who like what we’re trying to do.

I’ll be reading it with interest.

I’ve committed webapp-config v1.50 to the Portage tree. Testers sought!

phpgroupware seems to be a project that, if not dead, is certainly on life support.

Their main homepage has gone - even Google doesn’t have the page cached any more. SourceForce says that the project has migrated to Savannah, but the last release via Savannah was last year, and this year’s security releases have been through SourceForge.

I’ve masked the package, and will get around to dropping it completely after a suitable period of reflection.

I’ve started testing webapp-config v1.50, with a view to getting this into the Portage tree this weekend. This is the long-promised rewrite of webapp-config in Python, and it’s been done entirely by rl03 and wrobel.

I’ve just watched it install three of the fattest web-based apps in our tree - egroupware, phpgroupware, and gallery - and each one took just a few seconds to install.

So far so good

I’ve just released the first version of php-toolkit. This will be our collection of useful scripts for managing an install of PHP on Gentoo.

At the moment, the toolkit consists of php-select - a script which allows you to manage the symlinks and APACHE_OPTS settings. The eclasses in the overlay now use php-select instead of eselect to automatically create symlinks when dev-lang/php is installed.

We’ll be adding more scripts to php-toolkit at some point. One script will be php-cleaner, which will automatically recompile any PHP extensions that need rebuilding. I know that Luca is planning to add a script to switch PHP extensions on and off. Neither of these is likely to happen before we mark dev-lang/php stable.

Please test the php-toolkit, and let me know of any bugs or other problems.

I’ve been asked a lot this week to provide another PHP5 status update.

Stabilisation has had to take a back seat recently, as there’s been a number of PHP security fixes to process instead.

I’m in the process of finishing off our new script for managing the symlinks for PHP, and adding support so that it will switch mod_php4 and mod_php5 in Apache and Apache2 for you. I want it to be in the overlay for at least a week so that we can catch any serious bugs. If anyone uses amd64 w/ multilib, I could use your help in making sure the new script works correctly for you.

So I’m aiming for next weekend to be able to announce a new date for stabilising dev-lang/php and PHP 5.

Even though dev-lang/php is not stable, I’d encourage everyone to add the necessary entries to package.keywords and make the switch sooner rather than later.

Daniel, how could I possibly force you to read the news? I obviously can’t get you to read a GLEP about something you care enough about to blog against … so how am I going to get you to read news about something you don’t care about?

Seriously, I don’t want to force you to read news that doesn’t interest you. I don’t want to do that to anyone. That’s why there’s been no mention of making unread news a fatal error when trying to merge in a package, for example.

And I’m not interested in being able to stake a claim to some moral high ground. I’d encourage all Gentoo developers to be tolerant of anyone who chooses not to read the news, and who then comes onto IRC in need of urgent assistance as a direct result.

Of course, we’re all only human, and I’m sure that there would be a queue of devs lining up to say “serves you right”, but you’re happy to accept that, aren’t you?