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

Re: 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


Reply to: