I’m putting together a new conference talk, and I’d like your help and input.

Most Linux distributions ship with packages for PHP, but not everyone is happy with these packages. If you’re not happy with the PHP packages for a specific Linux distro (no matter how obscure), I’d love to hear what you think the problems are and (if possible) what the correct solution should be.

If you have something to say on this, please leave a comment below.


  1. Thomas Koch says:
    May 14th, 2009 at 9:21 am

    Looking forward to read more on this. Some PHP guys say, that distributions just suck in packaging PHP. Well, they see it from their perspective as a PHP dev.
    I think there are a number of trade-offs to consider:

    - Keep PHP consistent on all plattforms (including evil ones) vs. optimize the experience for your distribution
    - Have a packaging system for PHP (pear) equally on all plattforms vs. integrate nicely into the distributions packaging system
    - Make PHP “just work”, e.g. if somebody just wants to install Mediawiki and doesn’t know anything about PHP vs. allow to tweak PHP to the maximum

    That are the ones I can think of for the moment.

  2. David Coallier says:
    May 14th, 2009 at 9:46 am

    I would have to say that one thing that really annoys me is the way OS X has to play with the libxml libraries and headers. Also, ICU+PHP6 can be a pain to get running if you don’t play with the icu/source/config/mh-darwin it probably won’t configure for you. Solution is quite simple, at line 28 of that configure script, make sure you have:

    LD_SONAME = -Wl,-compatibility_version -Wl,$(SO_TARGET_VERSION_MAJOR) -Wl,-current_version -Wl,$(SO_TARGET_VERSION) -install_name $(libdir)/$(notdir $(MIDDLE_SO_TARGET))

    Hope this helps a bit :)

  3. Dave Marshall says:
    May 14th, 2009 at 10:01 am

    I’m not sure if it’s a problem as such, but debian/ubuntu change the way sessions are garbage collected, disabling the built in methods and opting for cronjobs. I think this is because they give only root read access to the storage directory, which I assume is a security measure for shared hosting?

  4. K says:
    May 14th, 2009 at 10:54 am

    On ubuntu php comes with the suhosin patch and some other patches. While it may be a security plus , they probably tested with security in mind. Php is much slower than a non patched version and in several occasions php segfaulted , while on the same non patched version did not .

  5. K says:
    May 14th, 2009 at 10:56 am

    And in some other distributions , php5 is still at 5.1.x , updating php requires you to hack in or add a new repository.

  6. Gregory Patmore says:
    May 14th, 2009 at 12:30 pm

    CentOS rpms for 5.2.9 come with pdo_sqlite drivers packaged, but no standard sqlite extension.

    Really a debate about what should be packaged with each distro is a moot point in my opinion. What I think should happen is that all rpms should come configured in conjunction with what the php manual SAYS it should be packaged with by default. Granted some extensions just plain old won’t work on some distros, but then we need to get them documented in a better fashion then 34 user comments down on the function reference page.

  7. Stuart Herbert says:
    May 14th, 2009 at 12:43 pm

    @gregory At this stage, I’m more interested in the problems caused by each distro’s changes to PHP. I plan on following up with an article summarising how all distros should ship PHP.

  8. Stuart Herbert says:
    May 14th, 2009 at 12:44 pm

    Many thanks to everyone so far for your comments. Please keep them coming!

  9. philip says:
    May 14th, 2009 at 1:55 pm

    I don’t remember or know the topic but RedHat seems to port various fixes (seen as security fixes) to 5.1 and distribute that.

  10. Mark Lee says:
    May 14th, 2009 at 8:37 pm

    I posted my gripe about Debian/Ubuntu and PEAR a while back:


  11. David says:
    May 15th, 2009 at 2:05 am

    What really bugs me is when distros take forever to upgrade to newer packages. I can understand the stability argument to a degree (you don’t want things changing all the time on live servers), but at the same time, minor point upgrades rarely add new features, and instead are bug fix releases. I have to agree with Torvalds when he said that focusing only on security is misguided. It doesn’t make sense to only take the security fixes and backport them to a previous version and ignore the bug fixes. I want PHP to work and run as expected. Not become a fragmented mess where the version you’re running is actually some weird hybrid of PHP versions 5.2.6, 5.2.8 and 5.2.9. And then it still says that you’ve got 5.2.6 installed which makes you wonder what security vulnerabilities have actually been fixed?

    Similarly with shared hosting accounts, if I see an older version of PHP installed, the first thing that comes to mind is that they’re using an older buggier version that still has widely publicised security vulnerabilities. Not something that instils a lot of confidence…

    Now if there was some easy way to get good up-to-date packages…

  12. Gaetano says:
    May 15th, 2009 at 10:28 am

    1 – (red hat and derivatives especially but other distros too) still shipping php 5.1 and having no 5.2 available in the main repos is really a hindrance to the community

    2 – the debian fix to session management is real bad if the admin does not know that he has to set session.gc_prob to != 0 (it usually igets discovered when the session table in the db is 10million rows)

    3 – having a non-sushosin-patched version in the main repos would also be good for those who prefer speed over security

    4 – having a different timezone db linked into php (redhat) can also be source of confusion (in exetremely rare cases, I admit)

    The biggest problem overall I’d say is making the info about distro-added patches and tweaks much more prominent and easily accessible.

  13. Stuart Herbert On PHP - » Poll: What server o/s will you run PHP 5.3 on? says:
    May 15th, 2009 at 12:39 pm

    [...] who voted in my last poll about when you’ll adopt PHP 5.3, and everyone who has provided feedback on the problems caused by the way individual distros package PHP.  I’ve had much more feedback than I could have hoped for!  This is all useful research for [...]

  14. David G says:
    May 15th, 2009 at 2:51 pm

    OSX (10.5.x) comes with MySQL and PHP+PDO. But PDO_MySQL is not compiled in so it’s a waste.

    Yet — OSX comes with SQLite and PDO and does come with PDO_SQLite (go figure).

    On pre 10.5 the easiest way to install PHP on OSX is to use a 3rd party distribution (Entrophy) which requires php-full-tags out of the box — and it kludges itself into Apache with a +entrophy.conf (hoping that “+e” is the first conf file including in your vhosts/sites configuration(s).

    On OSX 10.5.x GD is not installed by default with PHP rendering it useless for most work I do (Joomla / Drupal / custom) that requires image libraries be on the system.

    In case you can’t tell OSX blows … long live ArchLinux.

  15. Chuck says:
    May 15th, 2009 at 5:24 pm

    As an Admin/Engineer/Entrepreneur, I look at it from a point of view of maintaining or handing over control of this part of your software stack to a vendor. It depends how critical the application is to a business as to whether you decide to manage this part of the software stack or not.

    For example, if you’re an ASP you definitely want to maintain/manage as much of the entire software stack as possible. If you’re a small business running a CMS or a non-critical application then having the vendor maintain those packages may be a better choice.

  16. Peter Bowyer says:
    May 15th, 2009 at 6:05 pm

    How about the PHP-bundled GD fiasco on Debian/Ubuntu? Speak to Pierre-Alain Joye for the inside information :)


  17. Ray says:
    May 15th, 2009 at 6:30 pm

    I’ve noticed that in Ubuntu, php comes by default with the short_open_tag = On by default in the .ini file for apache (and i’m assuming the cli as well) In SUSE Linux Enterprise Server, short_open_tag = Off is the default there. I banged my head against a wall for like an hour before i figured out why apache with mod php turned on wouldn’t interpret … ( short_open_tag = Off requires you to write out … i guess to “improve portability pppppfftt! )

  18. Hartmut Holzgraefe says:
    May 18th, 2009 at 7:18 am

    I’ve never used PHP distro packages ever since back in 2002 or so, when:

    - RedHat had lots of obscure errors never seen elsewhere,
    probably due to their weird gcc-2.96 …

    - SuSE delivered PHP binaries with debug enabled, so breaking
    binary compatibility with 3rd party binary extensions …

    After this i’ve never tried anything but self compiled
    binaries ever again …

  19. Artur says:
    May 18th, 2009 at 7:33 am

    Well im using xampp on MAC OS X (because i have to at work) and for some unknown reasons it does not have some extensions in the command line interface. For example using apache module you have both soap extension available but running from command line you dont.

    So i had to compile the extension manually … but should not all core modules be included? at least as .so files?

    Another thing i rememer was missing was unixtojd function :-))

    From my experience with debian i never had any issues. Just install a few packages and then use pecl. Everything should work fine.

    btw. OSX does blow ;-)

  20. Adam says:
    June 1st, 2009 at 11:44 am

    I’ve got pretty wired Ubuntu gotchas with realpatch() function. In Ubuntu 8.04 Server LTS it returns false if file don’t exists and on Ubuntu 8.10 Desktop this didn’t worked (probably something that can be casted to bool true was returned). Both stock PHP packages (5.2.x) with minimal configuration changes. I haven’t tested this on newer Ubuntu version.