Distributions: Please Don't Cripple PHP or Red Hat: Stop Fucking Around

A friend of me pointed me to an issue in the Agavi issue tracker titled "Fucking Debian fucking ruined their fucking PHP package once again, and now we need to waste fucking time to fucking fix it)" . The issue is quite related to earlier discussions with the Red Hat folks about bundling a timezone database with PHP. Red Hat thought it'd be wise to create a patch to use the system provided timezone database instead. We (the PHP development team) thought that to be a bad idea because of several reasons. Among them is that it removes control from PHP's users about which database is, decreased performance, and some missing functionality. On top of that I mentioned that although the bundled timezone database is a concatenation of the system provided timezone database files, that might not necessarily be like that in the future. PHP does of course support means of upgrading the timezone database. For every release of the Olson database, there is now a bundled timezone database available through PECL .

Because of these reasons, we didn't want to accept Red Hat's patch to disable the bundled timezone database. The most important thing however for users of PHP that PHP works the same on every system . We, the PHP developers, see this as a much more important thing as a tiny bit of annoyance by distributions' maintainers to have to package the timezone database for PHP separately. Unfortunately the Red Hat PHP package maintainer proceeded to deploy this patch in RHEL and Fedora. SuSE, Debian and Ubuntu have since then picked up on it as well. So instead the Agavi issue's title should be " Fucking Red Hat fucking ruined their fucking PHP package and every other distribution once again, and now we need to waste fucking time to fucking fix it)". Unfortunately, this is not where it stops.

But first we go back on how PHP determines which timezone to use and what a timezone is. For PHP, a timezone is an identifier that describes UTC offsets and daylight savings times for a specific area, such as "Europe/Oslo" or "America/New_York". This identifier provides more information as just a timezone abbreviation such as "CET" or "EST", because abbreviations are not unique.

PHP determines which timezone to use with the following algorithm: First of all, if a call to date_default_timezone_set() is made, that's the timezone identifier that PHP uses. Secondly—although this is deprecated behavior—the "TZ" environment variable is checked. If it contains a valid timezone identifier, this is used. Thirdly it checks for a php.ini setting date.timezone. If the value is a valid timezone identifier, this is used. If neither of the above three methods succeed, PHP issues an E_STRICT warning and has to guess which timezone the current system is using. Although the guessing algorithm works reasonably well, it's not 100% accurate. This is also why the E_STRICT warning is thrown. In PHP 5.3 this has be increased to an E_WARNING type error instead to be more apparent that you are required to set a default timezone with php.ini's date.timezone setting. That the guessing algorithm isn't 100% correct can be demonstrated by setting your system's timezone to "Europe/London" and running:

php -n -r "echo @date('e');"

This will output "UTC" instead of the correct value "Europe/London". Because people do not set their date.timezone setting and have E_STRICT turned off, they never a see the warning. Instead of trying to understand the issue, they file a bug with their distribution . This distribution then adds a klugde instead of doing the proper thing . So now RedHat (and other distributions such as RedHat, Debian and Ubuntu) don't only cause performance issues, they also change the behavior of PHP. This of course is not making the developer's lives easier. This is bad for PHP's name and in my opinion a violation of our license term "3. The name "PHP" must not be used to endorse or promote products derived from this software without prior written permission.". I do not have problems with build fixes and packaging modifications because they are IMO not derivations of PHP. I do however have problems with people using the name PHP for crippled and intentionally broken derivations like the ones RedHat and Debian (and others) bundle. The whole idea behind this license clause is just to prevent exactly the mess that RedHat thought would be a good thing.

In the near future, when PHP 5.3 comes out, the timezone database that is bundled with PHP will no longer be compatible with the system version of the timezone database. I've mentioned that this could happen before . This change is made to provide extra functionality, and as a side effect breaks those stupid crippling patches that RedHat thought was a good idea!

Comments

I do not really mind about patches that alter speed of execution by introducing extra bounds checking or such, but changing functionality of php-the-platform is definitely a no go.

Debian a while ago changed their default php.ini setting session_gc_probability to 0 and adding a system cronjob to clean up file-base session storage. While not a difficult thing to fix per se, it can generate a hell of a lot of bug reports from (clueless?) users of your web app, if the said app stores its sessions in a db instead of the fs (hint: expired sessions will never be deleted until the db runs out of storage space). Then you have to either produce a huge amount of install docs with precise and detailed requirements or produce a huge amount of code that checks ini settings and sets them straight.

Add to that the code that works around the known bugs in every php version, and you get the perfect maintainability nightmare...

Right, and when in doubt about what qualifies as a "packaging fix" and what doesn't (aka a modification that would violate the license terms). A patch we have refused because we think its generally a bad idea is a good example of something that we do not consider to be a "packaging fix".

This is another good reason to manually build your PHP (yey for Gentoo ;-)) if your business/applications depend on it.

When it comes to binary packages you are always at the mercy of the distribution, which often tries to do the right thing, but not always successful as this case demonstrates.

I've really boinkin' had it with those package maintainers.

RHEL with a PHP compiled against five year old libxml versions and a PCRE version without UTF-8 support.

Debian and Ubuntu backporting security bugs, screwing up stream wrapper names.

And now this nonsense.

Why do they have to do this. Why do they think they know better. I don't get it.

P.S: The ticket mentions Debian because the corresponding RHEL ticket still has status "NEW" - Debian apparently were first to accept the change into their package.

If you are sure that php will be significantly harmed by this you could consider withdrawing permission for these distros to distribute any future versions of php in this manner. I suspect that would change things pretty quickly. A linux distro which doesn't provide a php through its standard package system would lose out to others which do.

Noel

Joe Orton is a confessed PHP hater ;)

This is not the only harm that distros such as RHEL do to PHP. Consider also the impact of refusing to up the PHP version for the entire lifecycle of a release -- in RHEL's case, this means that the only packaged version is 5.1.4 for up to 4 -- count 'em, FOUR -- years. This is a gross disservice to users of the distribution, as developers have to limit themselves to, in some cases, broken functionality until the next version of RHEL ships.

/me is sick of RHEL.

Well, that's why Wikipedia, for example, migrated 400 servers to Ubuntu Server. Red Hat was no longer an option. There's too much behavioural changes, massive amounts of unexpected updates and invalid documentation, not to mention a high chance of regression in stable updates. Red Hat is becoming very unreliable. In my previous job, we migrated 20 servers to Debian, and in my current job all our servers are running CentOS. If this trend continues, Ubuntu and CentOS will both gain enterprise acceptance very quickly as a result of Red Hat mistakes. They can do whatever they want with the packages, we can migrate to another OS.

Noel Darlow: why don't you go ahead and threat them to hang them high. Preventing them from packaging PHP will only add fuel to the fire. They will fork, and put everybody in an inextricable situation because developers and maintainers will be too busy flaming each other to care about users.

Package maintainers are not TEH EVIL (at least Debian's, I don't have any contact with others). They should be considered as part of the dev team of the software, in the wide sense of the term. Just speak with them, explain why what they did is wrong - with valid arguments, not trolls - and ask them to revert the change(s).

tl;dr: Communicate.

Makes sense - if they distribute a patched version as PHP, and the patch was not accepted into an official release, and is not purely for packaging ease, then it seems to clearly violate the license.

As someone said earlier, if you want to know exactly what you're using - compile your own :).

I wonder why there is not a single comment disagreeing with the article ...

@Federico: are you sure you know what CentOS is?

I agree that linux / windows timezones has limitations, but I don't agree that I need update my system, php, perl, python, java, and other languages timezones.

This is correct in theory, but a pain in practice. PHP people solve just their part of the equation.

"PHP can not simply use the default OS system calls as they do not expose enough information"

Strikes me that both RH and PHP seem to be implementing workarounds to the problem rather than fixing the underlying issue (OS APIs for TZ and poor system maintenance).

Agreed the former is a different scale of problem but IMHO fixing OS shortcomings in PHP is only marginally better than doing it in the application.

Politicians everywhere change timezone rules on a whim. In some cases, timezone changes were only announced 3 days before they were to take effect.

Having a handful of copies of the timezone database on a system seems like a really bad idea, since updating just one of them is enough of a pain as is.

What exactly does PHP need that is not already provided by the central timezone database in the OS?

Do the disadvantages of using the central timezone database in the OS really outweigh the risk of having different programs on the same system disagree about what time it is?

@Rik: Not every OS comes with the timezone database (Windows f.e.), and not every distribution provides all the identifiers (f.e. embedded Linux distributions). In order for PHP developers to be able to rely on timezone information to be available, we have to bundle it.

> are you sure you know what CentOS is?

Yeah, it's Red Hat without all the crap.

Seriously, if you are a PHP developer avoid using Red Hat, there are better alternatives. For example, Ubuntu server, Debian or even CentOS.

Those who have been using PHP for the last 10 years and are now Managers, migrate to a more reliable distro. The PHP community is huge. Your business depends on the technology you are using, choose a distro that supports it. You are now in a position to make this decision.

It's important to understand that Red Hat does not support PHP and will continue breaking your applications deliberately, costing your business a lot of time and money.

Migrate while you can.

@Frederico: well, I just checked the latest php package available from CentOS mirrors (ftp://ftp.icm.edu.pl/vol/rzm1/linux-centos/5.2/updates/SRPMS/php-5.1.6-20.el5_2.1.src.rpm) and guess what is at line 36 of the .spec file?

Patch32: php-5.1.6-systzdata.patch

... yeah, surely, all the "Red Hat crap" removed :-)

Here's a hearty "Screw You" to the Debian PHP package maintainers.

I just spent a good part of 2 hours figuring out why gdb completely failed to debug PHP executable and .so and the culprit was.. -gstabs in debian/rules. Yes, in their infinite wisdom they decided to go with that instead of regular -g. Thanks for nothing, you twerps.

@Derick: You have nicely side-stepped Rik's question: "What exactly does PHP need that is not already provided by the central timezone database in the OS?"

I don't see how Windows or embedded OSs not having a time zone database has any pertinence to the situation on OSs that do have one. Checking whether a central time zone database exists should be easy enough during build time and you can always fall back to using the embedded one on systems that need it.

As a "downstream" admin that has a lot of other tasks to accomplish I would be very interested in a systematic listing of all the errors that binary packages for debian and other distros provide - is there a database for this info right now? Also I would like to here waht is the favorable way of maintaining a php installation on debian or other distros. Not beeing deeply involved into what is discussed here I just keep wondering, why not are zend or other php devs like yourself generating the binary distro packages? Wouldn´t it be much better then if YOU provide the packages? Regarding timezone data: from outside the box it is hard to understand why every application and programming environment should come with it´s own timezone data - this seems a way back to middleage. If Windows absence of centralized tz data is the reason for that, then in the long run MS again managed to screw open source - they act like "how can we come together" and in fact their just implementing problems into open source projects with the long term goal to push their own technololgy.

I totally agree with Jones - why isn´t there an official deb source from php.net??? Who could do a better package than php devs himself??? Make a deb.php.net and stop compaining about others!

So PHP wants to make the same mistake as Sun did with Java?

Rik, I totally have to back you here, being that I work on world-wide defense and financial networks for Red Hat (as well as on systems and even embedded devices for world-wide financial applications prior to joining Red Hat).

We see the same problem with Java. It's bad enough that Sun can't keep up with Zoneinfo DB changes, let alone old versions no longer supported have the wrong Zoneinfo. All while the OS is correct.

Now PHP wants as they have their own Zoneinfo DB for resolution of Olson paths as well? Learn from Sun's Java, leverage the Zoneinfo DB in the OS when it's available.

I totally understand how PHP, like Java, wants to "standardize" on Zoneinfo DB, and that requires both PHP and Java to statically include Zoneinfo DB for resolution of Olson paths on non-POSIX systems with the Zoneinfo DB. But when it's there, in the OS, leverage it.

It's no different of an argument than dynamic v. static linking of libz, OpenSSL, etc... One library, one DB, etc... for the OS, when it's available. It's a simple autoconf detection and make an optional flag to override if you wish. But make the option to leverage the OS' Zoneinfo DB when available.

Heck, I still can't get people to store time as ISO 8601 with an Olson path instead of time_t in UTC. You'd figure half of Wall Street and the banking world would have woken up to that mistake on 2008 Jan 14 (when 30 year mortgages were hitting an end date of 2008 Jan 14, signed 32-bit POSIX time_t rollover), but they all didn't.

Some were still arguing 64-bit POSIX time_t as a solution. That solution still doesn't solve time/date prior to 1970, which many financial systems also need to store. Heck, because the Zoneinfo DB can change, even converting to UTC in real-time is not ideal, because the Zoneinfo DB might be out-of-date. I still cannot even sell that one to everyone, even when they recognize to use ISO 8601.

Sigh, some developers never learn.

Add Comment

Name:
Email:

Will not be posted. Please leave empty instead of filling in garbage though!
Comment:

Please follow the reStructured Text format. Do not use the comment form to report issues in software, use the relevant issue tracker. I will not answer them here.


All comments are moderated

Life Line