Oxan van Leeuwen writes:
> Currently Policy requires that init.d scripts, and only init.d scripts, don't
> fail if the corresponding /etc/default is removed (section 9.3.2,
> second-to-last
> paragraph).
[...]
> The other option is that "not fail" means that the init script is allowed to
> not
> start the daemon, but it shouldn't cause any further breakage. That seems
> like a
> sensible requirement to me, but the wording could use some clarification in
> this
> case.
I think we should keep the requirement. Legacy init.d scripts are still
handled as conffiles and kept around even if the package is removed
(unlike systemd unit files). Thus init scripts are still run[1] and
should behave sensibly.
For removed-but-not-purged packages, removing /etc/default/${foo}
probably shouldn't result in errors. So the init script still needs to
do something sensible (probably just do nothing).
(There are other problems as a sysvinit script cannot really be a noop
for removed-but-purged packages as the LSB header still does something,
but improving that is probably not too welcome as it would require
changes in sysvinit.)
Ansgar
[1]: For packages shipping native .service files for systemd, this
might mean that for removed-but-not-purged packages suddenly the
sysvinit script gets started? After all there is no longer a .service
files to prefer over the sysvinit script...
