Re: Some more patches
Raphael Geissert <atomo64+debian@gmail.com> writes:
> lintian_bad_php-licenses.patch:
> I couldn't find a clear reference where it is stated that the PHP licences
> v2.x are non-free, but using any of those licences is a pseudo-automatic
> REJECT when uploading to new. The check for version 3.0 just complements
> the set.
Not okay as-is. The PHP 3.x license is fine for PHP itself, so this test
would produce false positives for packages actually maintained by the PHP
project. If you can find a way of distinguishing those cases, the idea is
fine.
The PHP 2.x tag saying that it's non-free bothers me without a reference
from ftp-master that it's non-free, and I don't see anything about PHP 2.x
specifically in the REJECT FAQ. I'm personally not very comfortable with
Lintian making any judgements about licenses; the PHP
> lintian_TODO_typo.patch:
> Fixes a typo in the TODO.
This is fine -- applying this one.
> lintian_deprecated_sf_redirector.patch:
> Adds a check to checks/watch-file to warn whenever the sf.net redirector is
> called with some parameters other than a path (e.g. sf.php?project=foo
> instead of sf.php/foo/).
This is also fine, will apply.
> lintian_findstrin_DEB_BUILD_OPTIONS.patch:
> Adds two checks, one for the usage of 'findstring' on DEB_BUILD_OPTIONS
> instead of 'find', and another one for the usage of DEB_BUILD_OPTS.
The DEB_BUILD_OPTS part is okay.
I don't like the findstring check. Using findstring in debian/rules for
checking for noopt and nostrip and the like works fine in practice, was
recommended by Policy for years, and is very wide-spread. The only time
it would break is if someone used some other build option that contained
the string searched for, which seems extremely unlikely. I guess I could
maybe see an info tag suggesting using filter instead, but I think it's a
lot of noise for a very theoretical gain.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: