Dominic Hargreaves <d...@earth.li> writes:
> 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.
Hi all,
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.
--- 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``
> 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. 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.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
