>>>>> "Luca" == Luca Boccassi <bl...@debian.org> writes:
Luca> How would such a change look like?
I looked at your patch.
In most of the cases you are changing non-normative language.
That is, parts of policy that do not create a requirement.
For example:
>Scripts may assume that "/bin/sh" implements the POSIX.1-2017 Shell
>Command Language [7] plus the following additional features not
>mandated by POSIX.1-2017.. [8]
That creates no requirement on a package.
>* The term *may* and the adjective *optional* are used to clarify
> cases where it may otherwise appear that Policy is specifying a
> requirement or recommendation. In those cases, these words describe
I.E. in the cases you adjust, I think it is already
not a bug, and it would be inappropriate to use existing policy language
to complain about which interpreter path people use.
There is one case however where I think your patch adjusts normative
language.
I propose the following adjustment to your patch. Rather than mandating
a particular path for a csh interpreter, make it clear that the policy
requirement is that the csh script start with a #! line rather than
simply assuming csh will interpret the script as was all too common back
in the days of csh:
@@ -266,7 +266,7 @@ including ``open``, ``print``, ``close``, ``rename`` and
``system``.
Programming Considered Harmful*, one of the ``comp.unix.*`` FAQs, which
can be found at http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/. If
an upstream package comes with ``csh`` scripts then you must make sure
-that they start with ``#!/bin/csh`` and make your package depend on the
+that they start with the path of a csh interpreter such as ``#!/bin/csh`` and
make your package depend on the
``c-shell`` virtual package.
Any scripts which create files in world-writeable directories (e.g., in
I think the other hunks of your patch are unnecessary to avoid policy be
used to create bugs in this space.
