Re: [draft] Draft text on Init Systems GR

[Ansgar <ansgar@43-1.org>]

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
> be
>     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
> users
> sh> of default initsystems, normal procedures for judging
> sh> acceptable risk should be used.

There are various risks that seemingly innocent changes to support
alternatives trigger:

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

Ansgar