[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#399362: imapproxy: Bashism in init script



On 2006-11-25 Steve Langasek <vorlon@debian.org> wrote:
> Andreas,

> On Sun, Nov 19, 2006 at 06:34:53PM +0100, Andreas Metzler wrote:
[...]
>> So perhaps etch_rc_policy.txt could be amended to include "This
>> paragraph does not apply to  #!/bin/sh scripts using bash features."

> The release policy does not itself define what is an appropriate #! line.  I
> think this section of the release policy was written to mean "a script must
> have a #! line pointing to the interpreter it should be executed under,
> instead of depending on inheriting the correct interpreter from the parent
> shell."  If it had been intended to cover what semantics can be relied on
> for /bin/sh, that would have been spelled out.  (As will be done for lenny.)

"Will be fixed", is good enough for me.

>> cu and- Slightly unhappy upon realizing that he might end up with a
>> known to be broken system with dash as /bin/sh in etch. -reas

> Rather than quibbling over whether /bin/sh is an "appropriate" interpreter
> for a script using bashisms, I would encourage you to NMU imapproxy for this
> issue, since it's a candidate for 0-day NMUing as of tomorrow -- or else
> sponsor the maintainer's package, since he appears to have prepared a fix.

[x] done, as I have time to spend again and it still is open.

I did not mean to quibble, which is why I did not CC the bug. ;-)

> As for whether etch as a whole will support /bin/sh -> /bin/dash, I
> don't know any reason to think etch's support will be worse than
> sarge's, and it's my understanding that people have used dash as
> /bin/sh quite successfully in sarge.

Indeed I've been doing so myself, and apart from #314342 (zgrep broken)
I have failed to notice any breakage.
cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



Reply to: