Bug#267142: debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)
> Why? Section 10.4 restricts my use of the shell; but "test" is a
> Debian command, and not part of the shell specification at all. And
> if you say "but test is a builtin", then I respond, "but so debconf
> might be, and that's clearly allowed."
>
> But you can stick to your guns and say "debconf isn't allowed either".
>
> Either way, section 10.4 is broken.
I'll try saying this a different way. Expecting "debconf" to not be a
shell builtin is not "relying on a shell feature".
> The question however is not about "test -a"; it's a broader question,
> which is why I 1) did not change my package when someone complained
> about test -a, and 2) filed bug 267142 so that the situation can be
> clarified.
Yes, I realize that. I would be ignoring you otherwise.
> Once it's clarified, I will of course fix my package to comply. For
> example, if we go with the list-of-shell method, and posh is in the
> list, then of course I'll drop test -a.
Since you keep bringing it up, I'll bite.
If you have a list of shells, you need a decision-making process each
time you want to add or remove an entry from that list. If you happen
to add an entry, you risk making an indeterminate number of packages
instantly buggy. If a shell on the list changes behavior, it is still
on the list, and you risk making an indeterminate number of packages
instantly buggy. In this scenario, a shell on the list can do any
ridiculous thing and it will not be buggy; other packages will be.
Even now, if a #!/bin/bash script fails to run on bash 3, it isn't
necessarily clear where the bug lies.
Conversely, under current practice (even if this isn't exactly what 10.4
says), if you use brace expansions in a #!/bin/sh script, someone will
file a bug against your package saying "bashism! this doesn't work with
dash". Because brace expansions aren't POSIX, the onus is on you to fix
it. If your package fails because someone's using a SYSV-type "echo"
and you are relying on BSD-style "echo -n" functionality, your package
is not buggy because you are conforming to Debian policy, even though
the user in question may have a fully-POSIX-conformant setup.
I attach no importance to whether or not this hypothetical "echo" is a
shell builtin or a standalone utility, and I don't think 10.4 cares
either.
Reply to: