Raphael Geissert <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
