control: tag -1 +patch Hello, On Fri 24 Aug 2018 at 08:44PM -0700, Russ Allbery wrote: > I'm looking for seconds for this patch to relax the current requirement > back to a should. After that, I think the next step would be to introduce > automatic fixing of the #! line to debhelper, since that seems relatively > uncontroversial, and then we can reconsider this later after that's had a > chance to propagate through the archive. I agree that this is how we should proceed. > --- a/perl-policy.xml > +++ b/perl-policy.xml > @@ -533,7 +533,7 @@ $(MAKE) OPTIMIZE="-O2 -g -Wall"</screen> > <title>Script Magic</title> > > <para> > - All packaged perl programs must start with > + All packaged perl programs should start with > <literal>#!/usr/bin/perl</literal> and may append such flags as > are required. > </para> > diff --git a/policy/ch-files.rst b/policy/ch-files.rst > index f31a3b4..bc87573 100644 > --- a/policy/ch-files.rst > +++ b/policy/ch-files.rst > @@ -186,7 +186,7 @@ All command scripts, including the package maintainer scripts inside the > package and used by ``dpkg``, should have a ``#!`` line naming the shell > to be used to interpret them. > > -In the case of Perl scripts this must be ``#!/usr/bin/perl``. > +In the case of Perl scripts this should be ``#!/usr/bin/perl``. > > When scripts are installed into a directory in the system PATH, the > script name should not include an extension such as ``.sh`` or ``.pl`` Seconded, and given the other seconds, committed to git. >> 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! > > Yes, this is my feeling as well. It's all well and good to say that if > local administrators install their own Perl and things break, they get to > keep both pieces, but this seems unnecessarily fragile. Yes. My first thought when seeing this thread was dpkg-divert, which hasn't been mentioned yet. If a local admin wants to override perl such that all Debian-installed Perl command scripts use their custom perl, dpkg-divert seems like a semantically correct way to do that. And this method is far less susceptible to the various examples of breakage that have been brought up in this thread so far. > There are various ways in which some other Perl could be added earlier > in the PATH without the administrator having any intention whatsoever > to supplant system Perl with it. Consider, for instance, some local > application written using bleed Perl installed in some non-standard > path, some other program that with the best of intentions prepends the > location of that application to the PATH, and some program that this > application happens to run without even necessarily knowing it's > written in Perl. It seems better to ensure that this sort of pattern > just works. Yes. Users should not have to think very hard about the language in which stuff that Debian installs into /usr/bin is implemented. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature