Re: Debian Buster release to partially drop non-systemd support
Philipp Kern <pkern@debian.org> writes:
> I don't understand. If I submit a merge request to the maintainer, it's
> on me to test what I submit actually works. So if I add stuff for a
> completely different init system I have to test it. The question is: Is
> the package buggy if it does not contain an init script but a systemd
> unit and it seems to be the case. Note that there are a *lot* of useful
> options in a systemd unit that would need emulation to make properly
> work with sysvinit.
I think a package of a daemon that does not inherently require any
systemd-specific features and would work straightforwardly with sysvinit,
but has only a systemd unit file and no init script, is not only buggy but
RC-buggy. That's what Policy currently says.
It is quite easy to write a sysvinit init script for most daemons that
will basically work. I don't think the maintainer is obligated to do much
more than that (for instance, I don't think you need to try to duplicate
systemd hardening configuration or other features that are quite
challenging to do under sysvinit without more tool support, although some
of that may be coming in start-stop-daemon).
I don't think it's reasonable to expect every Debian maintainer to have a
system booted into sysvinit to test the init script, since that can be
quite an undertaking if one isn't using sysvinit normally, but thankfully
you don't need to do that to test the init script. Just delete the unit
file and then test the init script with systemd. For nearly all daemons
that don't involve tight system integration, this will be more than
adequate.
If you want to do more than the minimum and try to replicate more unit
file features in the init script, that's great, but I think it's also
reasonable to not do so and wait for sysvinit users to file bugs. But I
do think it's a key and important part of our general project-wide
compromise that maintainers of packages that include daemons continue to
do the reasonable minimum to keep those daemons basically working with
other init systems, until such time as the project as a whole decides that
sysvinit support should not be maintained.
> It'd need to run much more often (every 15 minutes). So cron.daily
> wouldn't fit. For the sake of the argument it'd need to be a shell
> script that checks multiple conditions (see [1]). And we currently don't
> have timer/cron deduplication, unfortunately. That means it'd also need
> to disable itself on systemd systems (but of course cron would still
> invoke the script periodically). Similarly - as a more general remark -
> having it as a cronjob doesn't let you monitor it in quite the same way.
I think we should solve the problem of timer/cron de-duplication before
opening the door to timer units. I agree that timer units would be a very
valuable addition to a lot of packages, but timer/cron de-duplication
feels like an entirely tractable problem that's useful to resolve in its
own right. Maybe we can just do that?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: