[php-maint] On php dependencies and lintian errors
ao2 at ao2.it
Thu Mar 17 15:29:00 UTC 2016
I am the maintainer of tweeper (I am also the upstream author BTW),
and since the introduction in Debian of the php7.0 packages I feet like
the dependencies of my package were a little too loose, let me explain
what I mean.
Right now tweeper dependencies are:
Depends: php5-cli, php5-curl, php5-xsl, php-xml-serializer
The package provides a tweeper executable with a shebang line which
Now, after I installed php7.0 I found out that tweeper didn't work
anymore with this error:
PHP Fatal error: Uncaught Error: Call to undefined function
curl_init() in /usr/share/php/tweeper/tweeper.php:54
The problem was that the executable was using /usr/bin/php which now was
a link to php7.0, so even though all the _install_ dependencies were
satisfied (namely php5-curl), they didn't reflect the runtime
dependencies. Installing php7.0-curl worked around the issue but
I started looking at the right way to fix the problem.
The first thing I thought was to depend on the php-* packages, the ones
without the explicit version in the names, I tried that but lintian
complained with a message like this:
E: tweeper: php-script-but-no-phpX-cli-dep usr/share/php/tweeper/tweeper
N: Packages with PHP scripts must depend on a phpX-cli package such as
N: php5-cli. Note that a dependency on a php-cgi package (such as php5-cgi)
N: is needlessly strict and forces the user to install a package that isn't
N: In some cases a weaker relationship, such as Suggests or Recommends,
N: will be more appropriate.
N: Lintian can only recognize phpX-cli dependencies for values of X that it
N: knows are available in the archive. You will get this warning if you
N: allow, as alternatives, versions of PHP that are so old they're not
N: available in stable. The correct fix in those cases is probably to drop
N: the old alternative. If this package depends on a newer php-cli package
N: that Lintian doesn't know about, please file a bug against Lintian so
N: that it can be updated.
N: Severity: important, Certainty: certain
N: Check: scripts, Type: binary
However, even if there was not the lintian error, depending on the php-*
dependencies won't cover the case when a user switches the default php
interpreter version using the "alternatives" system; a user could end up
having all the right php7.0 intall-time dependencies brought in by the
package but having /usr/bin/php point to php5 and and miss some run-time
dependencies, a situation symmetric to where I started.
So I thought that a better fix would be to make sure to use, at
run-time, the php version which corresponds to the package dependencies,
e.g.: to add a patch to the package to make the executable use php5
explicitly in the shebang line:
But then I read that there are plans to ship stretch with just php7.0,
so an even better fix could be to use php7.0 in the executable and
depend on the php7.0-* packages, I tried that but lintian complains with
the same message from above
So, what is the best way to go?
Is the last solution the preferred one?
Should I file a bug against lintian to add support for php7.0-*
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
More information about the pkg-php-maint