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