Hi,
Dominic Hargreaves wrote:
> On Tue, Aug 21, 2018 at 08:42:11PM -0700, 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.
>
> My personal view is that the rule is the correct one though. Installing
> a different perl for some application specific purpose is not uncommon -
In this thread, there are three possible rules proposed:
1. #!/usr/bin/env perl
2. #!/usr/bin/perl
3. Packager decides between 1 and 2, policy doesn't express a
preference.
The passage you are quoting is about the confusing user experience
that (3) provides: when someone installs a different perl to $PATH,
some Debian packages would use it and others wouldn't, with no
organizing principle to predict how each new package will behave.
I believe you are arguing for (2) as a long-term goal: all Debian
packages would then use /usr/bin/perl instead of the perl from $PATH,
while the sysadmin's own custom scripts using '#!/usr/bin/env perl'
would use perl from $PATH. I agree with you that that's a good place
to end up, similar to what we already do with python.
Ian and Russ also mentioned that there's a bit of an inconsistency in
spirit here with policy 6.1:
Programs called from maintainer scripts should not normally have a
path prepended to them. [...] These considerations really apply to
all shell scripts.
But as Ian mentioned, commands exist on a spectrum; most interpreters
are at an extreme end where hard-coding the path in *packaged scripts*
is generally the right policy, while commands like ls or git, say, are
at the other extreme where hard-coding the path would not accomplish
much useful.
So while this distinction between the interpreter of a script and
commands invoked within a script may feel arbitrary, in practice it
seems to work out pretty well. Best of all, it's predictable.
For some other languages (#!/usr/bin/env node?), matching convention
might lead us to a different conclusion, and that's okay.
tl/dr:
- in the short term, I agree that this should be lowered to a policy
"should", not "must"
- for the sake of the long term, I agree that debhelper should rewrite
to the #!/usr/bin/perl form
Thanks,
Jonathan
