Re: [draft] Draft text on Init Systems GR
On Fri, 2019-11-15 at 07:11 -0500, Sam Hartman wrote:
> Ian> * Declining to accept init scripts, or arguing against the
> Ian> inclusion of init scripts, on the grounds that they should
> Ian> properly tested by the maintainer and the author doesn't
> Ian> consider testing them to be a good use of time.
I guess the same applies to people refusing to include native systemd
services? Or ignoring patches that add such.
> Ian> Such contributions should be accepted, even
> Ian> if they are or may be of compromised quality, if the
> Ian> quality/risk is acceptable to the maintainers of non-default
> Ian> init systems and the surrounding community
> sh> and the risk will be born by the users of non-default
> sh> initsystems. To the extent that the risk will be born by
> sh> of default initsystems, normal procedures for judging
> sh> acceptable risk should be used.
There are various risks that seemingly innocent changes to support
- dependencies sometimes pull in alternatives, even though they
shouldn't be installed.
This causes unwanted behavior. Sometimes package managers will
propose very unexpected solutions.
Example: systemd-shim has popcon ~6000, noticably more than
sysvinit-core. Having systemd-shim installed, or
removed-but-not-purged, caused problems in the past when using
systemd's implementation for init & logind.
- the decision to require /etc/init.d/* to be conffiles causes
problems with removed, but not purged files. The only way to deal
with this is to remove problematic files in other packages which is
not a good solution.
Conffiles also are annoying when maintaining packages as they need
special handling which maintainers often forget (resulting in more
left-over, outdated files which might cause problems at unexpected
later times). They are also annoying for users; Debian has two
different override mechanisms for /etc/init.d/* so users don't have
to deal with the problems: /etc/default/* and the lesser known
/etc/insserv/override/* & /usr/share/insserv/override/*.
As we *require* init implementations to use /etc/init.d/* this
causes even problems when native systemd units are provided as
those get properly removed and thus the sysv-compat layer gets
activated. (A policy question: do we require alternatives to also
support the /etc/insserv/override & /usr/share/insserv/override/*
mechanisms that provide dependency information for sysvinit script?)
There is also the stateless-system ideas that some people are
interested which is easier the less config files in /etc are.
(Sadly sysvinit refused to support alternatives such as also
looking into /usr/lib/init.d/* in addition to /etc/init.d/* or
such; it would be nice if they were open to make it easier to
support sysvinit without running into such problems.)