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

Personally I interpret "not fail" as "succeed to function", i.e. it has to
actually start the daemon. I don't think that's a particularly sensible
requirement. Policy doesn't require programs to function if their native
configuration files are removed, so why should default files be any different?
Furthermore, this requirement doesn't exist for systemd unit files, and there
are in fact unit files in the archive that fail if the default file is removed.

Also, to me removing configuration files seems like a "don't break your system"
kind of action. If the system administrator does it, they get to keep the pieces
and are reponsible for the fallout.

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.

Oxan van Leeuwen writes:
[...]

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

'not fail' here means that the script terminates with return code 0.

Cheers,

On 30-11-2020 19:28, Ansgar wrote:> I think we should keep the
requirement.  Legacy init.d scripts are still

I don't think this requirement is necessary to handle that case. There
is already a separate, explicit requirement for init scripts to not fail
for removed-but-not-purged packages a few paragraphs before, and Policy
explicitly states init scripts should use ``test -f daemon || exit 0''.

At least for packages using debhelper that's not the case, as
dh_installsystemd (and its predecessor dh_systemd_enable) mask the
service on package removal.

Cheers,
Oxan

Hello,

This is how I would read it too.  Would a patch to add "(i.e. exit with
return code 0)" resolve the original submitter's concerns?

Hi,

Though I'm still not convinced it's a sensible requirement, that
clarification would resolve my main concern (i.e. having to fix init
scripts to work with an absent defaults file). By the way, there's an
identical requirement a few paragraphs before, so it might be good to
insert the same clarification there as well.

Cheers,
Oxan

Hello,

Okay, cool.  Patches welcome!