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

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



Andreas,

On Sun, Nov 19, 2006 at 06:34:53PM +0100, Andreas Metzler wrote:
> [...]
> >>> if [ "$START" == "no" -a "$1" != "stop" ]; then
> [...]
> >> It appears dash and posh chokes on "==" above. A single "=" is
> >> enough and POSIX.

> > This is not a release-critical bug under
> > http://release.debian.org/etch_rc_policy.txt, but it is a candidate for
> > NMUing under the release team's 0-day NMU policy per the latest release
> > update mail to d-d-a.

> Hello,
> <mode=nitpick>
> http://release.debian.org/etch_rc_policy.txt says: 
> (g) Scripts

>         Scripts must include the appropriate #! line, and set executable.
>         The package providing the script must Depend: on the appropriate
>         package providing the interpreter.

> A script setting #!/bin/sh but failing to work if /bin/sh = dash fails
> to fullfill this requirement, #! line is not "appropriate".
> </mode>
> 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.)

> 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.

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.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Reply to: