On Tue, Aug 21, 2018 at 08:42:11PM -0700, Russ Allbery wrote: > Russ Allbery <ea...@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.