Re: Problem while checking for php-cli
Thomas Goirand <thomas@goirand.fr> writes:
> At the end of this message is the exact message. Lintian "thinks" that
> there is no dependency to php5-cli. That's when using this in my control
> file:
>
> php5-cli | php-cli | php4-cli
>
> or if I set only:
>
> php5-cli | php4-cli
>
> The only thing that removes the lintian warning is to set:
>
> php5-cli
>
> only.
Right.
> When reading the lintian warning, it makes me feel that I should be able
> to use at least php4-cli, maybe php6-cli when it's out, but in fact the
> only thing that works is php5-cli only.
The only thing that works is listing PHP packages that are in the archive.
If you list an alternative that isn't in the archive, Lintian will
complain, since it has no way of knowing that alternative would satisfy
your script's requirements.
I'll add an additional explanation to the tag that there's no such package
as php-cli and listing it isn't helpful. (In fact, as long as you include
php-cli in the alternatives, Lintian will *always* complain.)
> Would it be possible in the future, that lintian checks that in the
> following Depends: statement
>
> a | b | c
>
> there is at least one package of a, b or c, that matches the following
> regex:
>
> ^php{39}-cli$
>
> instead of the current behavior of lintian?
Lintian doesn't know which of the dependencies in Depends, Recommends, or
Suggests is there for this script. Instead, it applies implication logic
across the entire dependency set. It's not doing regex matching; it's
testing whether all of the package dependencies satisfy a requirement of
php5-cli.
Implementing something like this would require rewriting the package
depencencies before checking the implications to remove alternatives that
are, from Lintian's perspective, uninteresting (such as php4-cli). That
in turn requires doing regex matching and substitution against the
dependencies of the package, which is tricky and fragile.
It's possible, but it's a big change. Without being done carefully, it
would reintroduce all the problems that we had with this check before I
switched it to using the Dep parser.
Handling alternative implications is surprisingly tricky. The code has to
be able to deal with things like:
ruby1.8 [amd64] | ruby1.6 [!amd64]
and be able to figure out that that satisfies a ruby | ruby1.8 | ruby1.6
requirement.
> Would it be considered good regarding current version of lintian to do a
> lintian override so that my package is also compatible with etch?
I think the best short-term solution would be for me to add php4-cli as a
recognized version for the time being, which means that you shouldn't
change anything about your package. You don't need to add overrides for
bugs in Lintian.
I'll do that for the next release.
PHP command-line scripts are one of only a few versioned interpreters in
Debian that don't provide an unversioned package for scripts that work
with any version to depend on, which is why you're running into this and,
say, the Ruby and Python folks aren't.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: