Maintaining the cc: to debian-perl@l.d.o as the discussion has started
there. Feel free to strip it out if you think isn't appropriate.
* [Mon, Aug 06, 2012 at 08:38:56AM +0900] Charles Plessy:
[...]
Here are possible resolutions of this bug report.
- Close, given that there is no internal contradiction within the
Debian Policy nor the Perl policy.
This seems fair enough, but ...
- Reduce the Perl policy's "must" to a "should". A "should" still
disallows the use of /usr/bin/env with no justification. It is also
in line with the fact that some packaged modules sometimes slip in
Debian with scripts started with /usr/bin/env, without this being a
serious bug requiring immediate action.
- Change the Debian Policy's section 11.9 to require that the Perl
policy "must" be followed. I think that this would require to correct
the packages that would become buggy according to that change,
including those with scripts starting with /usr/bin/env. But if it is
a reachable target, why not ?
... imho, merging these two points would be better. I mean:
- Change the Debian Policy's section 11.9 to require that the Perl
policy "must" be followed.
For the sake of clearness and because this way we can remove a sort of
indeterminateness caused by a perl policy that should (and not must) be
followed. As a general rule, I support the idea that also other specific
(python/ruby/java/...) policies could be a "must", so becoming a sort of
appendixes to the "general" policy.
AND
[ regarding `/usr/bin/perl' in the shebang line ]
- Reduce the Perl policy's "must" to a "should".
Because, apart from the reason above, I think there are some legitimate
(though unusual) reasons for using /usr/bin/env. I'm thinking for
example to a script that could copy itself to another (possibly not
Debian nor Linux) host for remote execution. Something like what the
sshuttle (python) script does.
@debian-perl people: do you think the perl policy as it stands (minus
eventually the shebang must) could be a "must" policy?
Side remark: for Python, section 1.4.2 of its policy also restricts the
use of /usr/bin/env under a "should not" directive, in line with Debian
Policy's section 10.4 that requests the scripts to started with a
"shell", which /usr/bin/env is not.
I was submitting a patch to lintian for including a check against the
use of /usr/bin/env in perl scripts and just remembered this sentence
from you. Could you please clarify the last point?
$10.4 reads:
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.
As for my interpretation, '#!/usr/bin/env perl' still names the "shell",
even if not giving the full path, so it does not violate that
requirement. But if it's not the case, should we have a lintian check
that warns about the use of /usr/bin/env whichever the real interpreter
is ?
Ciao,
Gian Piero.
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121016211750.gd10...@caimano.fdc.rm-rf.it
