Re: init.d script not using !/bin/sh
On 10/02/14 14:55, Jonathan Dowland wrote:
> On 09/02/2014 13:14, Thomas Goirand wrote:
>> Is it too late to fix this as a release goal, so that we get every
>> init script to use /bin/sh?
>
> Whether this is worth the effort or not (and not just *your* effort, the
> effort of maintainers of packages with init scripts, even if just to
> review and apply patches) depends entirely on the ctte outcome, and any
> follow-up GR
I'd go further than that: even if we use LSB-style init scripts[1]
forever, I still don't think porting init scripts from #!/bin/bash to
#!/bin/sh is a particularly productive use of anyone's time; and in
particular, I think NMU'ing for it (as would be enabled by a release
goal) is actively harmful.
If an init script uses bash features and correctly has #!/bin/bash, at
worst it slows the boot down a bit while bash is loaded into memory. Not
perfect, but "good enough". I don't think "a minority of init scripts
aren't as fast as they could be" is worth much of anyone's time - the
fact that the majority of init scripts run under /bin/sh means we
already have the majority of the potential speed benefit from dash.
Meanwhile, the largest practical difference between "mass bug-filing"
and "release goal" is that the NMU guidelines are relaxed for release
goals. The init scripts that have #!/bin/bash are, as a first
approximation, those where the maintainer looked at the init script's
use of bashisms and decided that changing the script to use /bin/sh
syntax and semantics was too difficult, or had too much risk of
regressions, or would make the script too hard to maintain, or is
otherwise undesirable. Those seem like exactly the sort of init scripts
that should *not* be NMU'd without a very good (= release-critical) reason.
S
[1] as used by sysvinit + (sysv-rc or file-rc) + insserv
Reply to: