[php-maint] On php dependencies and lintian errors

Ondřej Surý ondrej at sury.org
Thu Mar 17 15:51:06 UTC 2016


Hi Antonio,

On Thu, Mar 17, 2016, at 16:29, Antonio Ospite wrote:
> Hi,
> 
> 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
> says:
>   #!/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

Just ignore lintian for now. We will have to fix lintian at some point
in time.

This was the most correct solution. Thank you for looking into it.

> 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 install-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.

That should not happen in stable release, as we will have only one
version of PHP in stable release. So it's safe thing to do.

> 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

Nope, php5 won't be present in stretch.

> 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

Please, don't do that as this would prevent future transitions.  Unless
you feel that the PHP code in the package is so version specific that
you'll have to rewrite it for each new PHP version anyway.

> Should I file a bug against lintian to add support for php7.0-*
> dependencies?

If you have time, please write up the draft of the bug and post it to
the list, so we can finish it. Basically all php5-* should be turned
into php-*.

Every package with multiple extensions (with a grain of salt) now also
have correct "Provides" for every extension inside, so you can even use
that to finetune the dependencies.

Cheers,
-- 
Ondřej Surý <ondrej at sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server



More information about the pkg-php-maint mailing list