[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian-policy: Perl script shebang requirement is disturbing and inconsistent with rest of policy


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

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.


- 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


Reply to: