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/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7