[php-maint] On php dependencies and lintian errors

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

On Thu, 17 Mar 2016 16:51:06 +0100
Ondřej Surý <ondrej at sury.org> wrote:

> Hi Antonio,

Hi Ondřej,

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

OK, thanks. Please consider fixing the lintian issue sooner rather than
later, it is rather confusing that lintian reports an as error what is
in fact the recommended practice.

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

OK, thanks.

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

I'll try to sketch a report.

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

Does that mean that lintian should allow both the php-* deps, which are
the recommended ones, and the phpX-* ones, which can be used for version
specific tuning?


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