Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Sat, 21 Nov 2020 at 10:42:04 +0100, Vincent Bernat wrote:
> I don't think this is very common. Init scripts are very specific to a
> distribution. A Debian init script cannot be used for Redhat. A SUSE
> init script does not work with Redhat. I find doubtful that the
> compatibility would be better with the BSD init scripts (this may not be
> what you meaned). AFAIK, OpenBSD does not use initscripts. A FreeBSD
> initscript is unlikely to work on any Linux as it sources /etc/rc.subr.
>
> From my experience, when upstream ships an init script, this is usually
> unsable by most distributions (not to the standard), so it has to be
> rewritten. Init scripts are not contributed upstream as upstream doesn't
> want to handle all this complexity.
For what it's worth, as an upstream and Debian maintainer of dbus, I
removed the LSB-style init scripts for Red Hat and Slackware from the
upstream source code of dbus, because nobody was testing them and so I
had no confidence that they continued to work (Red Hat moved to Upstart
and then to systemd, and Slackware used their own init script instead
of the one provided upstream, so the relevant downstreams were not even
using the versions that were part of dbus stable releases, and they
certainly weren't testing development releases).
dbus in Debian continues to have a LSB init script that was never sent
upstream; Debian is better-placed to maintain that than upstream is (even
though at the moment it would be me making changes either way!), and it
can continue to take advantage of Debianisms like start-stop-daemon.
The LSB/sysv-rc interface (execute arbitrary code, which is going to be
a lot simpler if it relies on distro-specific facilities like
start-stop-daemon) does not really lend itself to writing portable init
scripts. The few portable init scripts that I have seen have generally
had robustness issues, precisely because they bend over backwards to
avoid using distro-specific facilities.
Echoing what Vincent said, my experience has been that systemd units *can*
typically be used unmodified across distributions - partly because they
are declarative, partly because the upstream part of systemd provides
facilities to do typical system service things without having to open-code
them or rely on a helper like start-stop-daemon (for example tracking
lifetime, dropping privileges, and sending SIGTERM to terminate gracefully
or SIGHUP to reload), and partly because the "drop-in" mechanism gives
us a way to add distro overrides where needed without necessarily having
to patch the unit.
smcv
Reply to: