Bug#906901: debian-policy: Perl script shebang requirement is disturbing and inconsistent with rest of policy
On Tue, Aug 21, 2018 at 08:42:11PM -0700, Russ Allbery wrote:
> Russ Allbery <eagle@eyrie.org> writes:
>
> > Did Lintian have some special case that was allowing /usr/bin/env perl
> > previously and then Lintian changed based on Policy? That would be
> > unfortunate, since we thought we were changing to match Lintian....
>
> Sigh. Yes, indeed.
>
> * checks/scripts.pm:
> + [CL] Policy 10.4 states that Perl scripts must use /usr/bin/perl
> directly and not via /usr/bin/env, etc. (Closes: #904414)
>
> in Lintian 2.5.94.
>
> Well, this is a mess. Apparently a lot of people were ignoring that part
> of Policy, and now we've created a ton of buggy packages because I made a
> bad assumption about what Lintian was already checking for.
Oh, that's really unfortunate :(
> Perl folks, the short version is that Lintian wasn't actually checking for
> scripts that used /usr/bin/env perl, so our check when we closed #683495
> was bogus. Lintian has now changed based on Policy, and it looks like
> there were around 2,000 scripts in Debian that were using the /usr/bin/env
> perl form.
>
> Any feelings about where we should go from here?
Clearly it should not be a must at this point given the deviation:
though it still looks to me like a must ever since it was added to the
perl policy, so if it is changed it should be changed in both places.
> 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 -
some people choose to not use the system perl at all when they are
deploying a perl application - and they should be free to do that by
putting a different perl in the path. That doesn't mean that they
suddenly have to worry about parts of the packaged Debian system breaking.
I certainly couldn't name every part of Debian that I rely on that's
written in perl!
Addressing your inconsistency argument above: I can certainly see an
argument that some types of perl scripts shipped in Debian might want
to opt into being run by a different interpreter for special reasons,
but I think they should be the exception rather than the rule. Having
a few special cases in Debian seems far better than having every single
perl script in Debian be at risk of breaking when /usr/local/bin/perl
appears.
Dominic.
Reply to: