Philipp Kern <pk...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>