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
