Bug#533571: [checks/init.d] multiple corrections and enhancements
Raphael Geissert <atomo64+debian@gmail.com> writes:
> Russ Allbery wrote:
>>> The init.d-related checks I still plant to write are:
>>> * init.d-script-is-foo.sh-but-not-bin-sh
>>> Basically making sure *.sh scripts use /bin/sh. This would have been of
>>> more use when Policy still stated that script might be sourced.
>>> Maybe with a severity/certainty of minor/certain?
>> My instinct says minor/certain with a willingness to downgrade to
>> wishlist or pedantic if anyone complains. There are enough reasons
>> why writing an init script in something other than sh are a bad idea
>> that I'd like to try it as a warning.
> I think minor should be fine, since having a foo*.sh* init script with a
> bash shebang is kind-of confusing; wishlist at worst, IMHO.
Oh, I'd actually missed that you were restricting it to only *.sh
scripts. Yeah, that seems fine to me. I wonder if we might want a tag
(maybe just pedantic) for any init script not written in a Bourne shell
varient, since it's going to make it a lot harder to do things like
adopt LSB reporting functions.
>> I'm not sure we're going to get enough accuracy on the file scan to
>> be able to say we're certain, though. I'm thinking of init scripts
>> that have optional actions that aren't one of the ones run during the
>> build, possibly implemented with shell functions.
> Hmm, indeed; I was thinking about using $LEADIN (which reminds me I
> need to find a way to reduce the code duplication that this would lead
> to between checks/scripts and init.d) to extract the names of the
> commands being used.
Yeah, my concern is that one of those optional targets will run
something from /usr, but the main part of the script will be fine, which
is a case where someone will need to add an override.
> After a quick scan on a set of packages I only found htdig to be using
> a 'foo = bar' format, and tor calling ulimit from there. In general I
> agree with the current requirements, as it ensures that any logic is
> performed directly on the init script and not in the configuration
> file (not to mention that the init script is supposed to be able to
> live and behave decently without it).
Yup, makes a lot of sense to me.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: