[php-maint] On php dependencies and lintian errors

Antonio Ospite ao2 at ao2.it
Thu Mar 17 15:29:00 UTC 2016


I am the maintainer of tweeper[1] (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
  #!/usr/bin/env php

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:    needed.
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:
  #!/usr/bin/env php5

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-*


[1] https://packages.debian.org/sid/php/tweeper
[2] https://git.ao2.it/tweeper.git/

Antonio Ospite

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

More information about the pkg-php-maint mailing list