Comment 23 for bug 74647

On Thu, Aug 27, 2009 at 10:49 AM, sean finney<email address hidden> wrote:
>
> how about you provide a list of what's missing?  this would be very
> informative to have.

PHP 5.2.9-0.dotdeb.2 with Suhosin-Patch 0.9.7 (cli) has the following
functions that are missing from Debian/Ubuntu 9.04 Jaunty:

function imageantialias
function imagecolormatch
function imageconvolution
function imagecreatefromxbm
function imagecreatefromxpm
function imagefilter
function imagelayereffect
function imagerotate
function imagexbm

> software.  this is not a "religious issue" as you suggest; there is a
> sound technical argument why debian as a distribution can't take this
> approach.

Well, could we not consider the GD inside PHP some other package? Call
it "GE" or "GC". Just happens to be compatible with GD. After all, the
intent of open source is to allow forks, so just consider it a fork.

But that is all debatable. Debian authorized archives are certainly
free to choose their versions.
Would be so much easier on users, though, if such archives clearly
said "well, there are quite a few functions documented on php.net that
won't really work on a Debian-authorized LAMP stack"

> in closing, there are really only two options for moving forward:
>
> 1) come up with a list of the missing features/functionality, and ship it
>   in README.Debian.  There could also be some instructions for how someone
>   could build the php5 packages with the embedded libgd.

Inside a README won't help most users - sure, after a few days they
will figure it out, but would be nice if something more prominent was
mentioned right when we do a "apt-get install"
or similar.
php.net loudly documents " Note: This function is only available if
PHP is compiled with the bundled version of the GD library." on these
functions.
So, a similar warning could be placed on the Debian php5-gd " Note:
All PHP functions that require bundled version of the GD library will
not work using this package".

> 2) convince the folks working on libgd (upstream) to roll a new release
>   with the missing features synchronized in, and then convince the debian
>   maintainer to update to the latest upstream version.  or alternatively
>   just identify the fixes and submit them as patches to both upstream and
>   the debian maintainer--this will likely move things a bit quicker.

This I presume will not happen given the personalities and issues
involved! So us users have to do the best we can - just need things
named correctly so we can pick the right thing!

>        sean

Here's a nice explanation of what has to be done :
http://drupal.org/node/134331#comment-1120427
Much better than compiling from source - since compiling means having
to patch manually, etc, while there is a greater chance that external
archives (like dotdeb) might keep their versions up to date.