Bug#906901: debian-policy: Perl script shebang requirement is disturbing and inconsistent with rest of policy
On Tuesday, 21 August 2018 20:42:11 AEST Russ Allbery wrote:
> I do feel like allowing either based on the whim of the packager is just
> kind of bad. It produces inconsistent behavior to no real benefit for
> anyone. If you install a Perl earlier in your PATH, you get totally
> unpredictable behavior, and everyone will be unhappy half the time.
Perhaps a useful data point in looking at standard practice within Debian:
A parallel discussion was had around python packaging some time ago and these
exact same arguments were felt to be persuasive: packaged utilities should be
robust against accidental breakage where possible. (In the current python
policy, it is only listed as "preferred", however.)
https://www.debian.org/doc/packaging-manuals/python-policy/programs.html
Avoiding "/usr/bin/env python" in packages is almost universal. The dh_python2
and dh_python3 helpers do shebang rewriting by default and only one package
elects to skip that. (There are 14 explicitly-python-using packages that don't
use these helpers plus some packages with python scripts but no explicit
python dependency, many of which have curiously overridden the lintian error
complaining about that and are presumably content to ship broken scripts.)
https://codesearch.debian.net/search?q=--no-shebang-rewrite
https://lintian.debian.org/tags/python-depends-but-no-python-helper.html
https://lintian.debian.org/tags/python3-depends-but-no-python3-helper.html
https://lintian.debian.org/tags/python-script-but-no-python-dep.html
Sidenote: Getting rid of env in shebangs is only part of the story to making
packages robust against accidental breakage. Putting an incompatible
interpreter into PATH (say, /usr/local/bin/{python,perl}) ends up breaking
maintainer scripts that call the interpreter without specifying the full path
in the same way as a dysfunctional /usr/local/bin/rm would break maintainer
scripts that call 'rm'. The differences are that people seldom compile their
own coreutils and the interpreter is also reliant upon a compatible module
tree and that is not necessarily available to the locally installed
interpreter. (Python people are strongly encouraged not to use /usr/local/bin/
python for precisely this reason, using, say, virtualenv instead.)
cheers
Stuart
--
Stuart Prescott http://www.nanonanonano.net/ stuart@nanonanonano.net
Debian Developer http://www.debian.org/ stuart@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Reply to: