Bug#917790: lintian: please split wrong-path-for-interpreter into wrong and broken
Hi Chris,
On Sun, Dec 30, 2018 at 02:52:46PM +0000, Chris Lamb wrote:
> > Currently wrong-path-for-interpreter lists both paths that are wrong, but work
> > (like '/usr/bin/env perl') and paths that are wrong, and don't work (like
> > '/usr/bin/bash').
>
> I'm afraid I can't quite 100% parse what you mean here; work/don't
> work? An example or link might be really helpful, especially for the
> usrmerge case too.
Hmm. It seems I wasn't clear. I'll try to rephrase (let me know if it still
isn't clear).
The matches for wrong-path-for-interpreter currently fall roughly into 2
different categories:
- interpreters that are not expected to work (I called these 'broken' in my
previous mail)
Examples of these are
/usr/local/bin/perl
/bin/perl
/usr/bin/bash
These scripts will not work and these packages probably deserve to be
autorejected.
The last 2 examples (/bin/perl and /usr/bin/bash) can be caused by builds in a
usrmerge chroot (they could also just be hardcoded by upstream).
Currently, udd has 4 cases like this (excluding overrides):
select * from lintian where tag='wrong-path-for-interpreter' and tag_type not in ('overriden') and information not like '%/usr/bin/env%';
package | tag_type | package_type | package_version | package_arch | tag | information
-------------------+----------+--------------+-----------------+--------------+----------------------------+-----------------------------------------------------------------------------------------------------------------------------------------
arcanist | error | binary | 0~git20180509-2 | all | wrong-path-for-interpreter | usr/share/arcanist/src/lint/linter/xhpast/rules/__tests__/php-open-tag/php-tags-script.lint-test (#!/usr/bin/local/php != /usr/bin/php)
fcm | error | binary | 2017.10.0-3 | all | wrong-path-for-interpreter | usr/bin/fcm_test_battery (#!/usr/bin/bash != /bin/bash)
mariadb-test-data | error | binary | 1:10.3.11-2 | all | wrong-path-for-interpreter | usr/share/mysql/mysql-test/plugin/rocksdb/rocksdb/slow_query_log.awk (#!/bin/awk != /usr/bin/awk)
perl-modules-5.26 | error | binary | 5.26.2-7 | all | wrong-path-for-interpreter | usr/share/perl/5.26.2/Config/Perl/V.pm (#!/pro/bin/perl != /usr/bin/perl)
(4 rows)
fcm and mariadb-test-data might be caused by usrmerge, the 2 other ones are
probably broken upstream (perl-modules-5.26 is cruft from an old version, so
that one is not important).
- interpreters that work, but are in violation of policy (10.4)
The most common example is '#!/usr/bin/env perl'. There are currently 1016
matches for that (excluding overrides).
While this is wrong and should be changed, these scripts do work. And given
the large number of packages involved, adding an auto-reject for this case
would probably cause more issues that it might be worth.
So my suggestion is to split this tag into 2 tags: 1 for interpreters that are
'broken' and 1 for interpreters that are wrong (according to policy), but
still work. Having 2 different tags would allow the first tag to be
autorejected, while still accepting packages with '/usr/bin/env perl' and
similar.
> (Shouldn't we split this bug into two? One for any "brokenness" and one for
> splitting it?)
>From this question, it seems you think I was suggesting that lintian is
somehow broken. That is not the case. The 'brokenness' was referring to
scripts in packages that don't work (or at least, don't work on a generic
system). What lintian currently does is correct, my question is just to make
it more specific, to allow easy distinction between different types of scripts
that trigger this tag.
Thanks,
Ivo
Reply to: