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

[Julian Andres Klode <jak@debian.org>]

On Wed, Aug 22, 2018 at 07:04:10PM -0700, Jonathan Nieder wrote:
> 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.

In fact, we're seeing upgrade failures due to people having different
interpreter versions in /usr/local, and there was some discussion about
dpkg specifying a safe PATH. There was no consent about that, but it seems
likely that APT will start specifying a safe PATH=/usr/sbin:/usr/bin:/sbin:/bin
eventually to prevent users from breaking their systems.


> - for the sake of the long term, I agree that debhelper should rewrite
>   to the #!/usr/bin/perl form

I agree. Let's put it this way: As a user I don't want to know whether
the program in $PATH is a Perl script or not and then have to deal with
local perl installations. I installed a tool, not a script, it should
not stop working due to some unrelated change.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en