On 2018-10-16 14:36, Ian Jackson wrote:
Philipp Kern writes ("Re: Debian Buster release to partially drop non-systemd support"):Could someone reiterate about what the current state of init diversity is supposed to be? Is it assumed to be best effort of every maintainer being required to ship an init script next to the systemd unit that is actually used by default[1]?I think describint that as `effort' is rather much.
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.
Can we rely on sysvinit users to report the bugs with the scripts or how intensively do they need to be tested?You should rely on users to report bugs.
Okay. In this case I contributed to the package of someone else and don't want to make it buggy.
Similarly, are maintainers allowed to ship timer units in lieu of cronjobs? As an example I invested some time in prometheus-node-exporter[2] to run textfile collectors of monitoring data (SMART, apt) in the background. Would I have been required by policy to make sure that all of this also works on a system with sysvinit?Obviously it would be better to make ti work with cron. Ideally it would go into cron.daily which I assume works with systemd too.
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.
But if you do just the systemd thing, I think if someone sends you a patch to make it work with cron I think you should accept and carry that patch.
In this case that might be feasible because if it breaks that user is hopefully going to monitor it anyway, because it's a monitoring thing. But there is a cost to carrying such things (such as cron confusingly invoking something whose output isn't used at all because it's going to be short circuited at startup).
Kind regards Philipp Kern[1] https://salsa.debian.org/go-team/packages/prometheus-node-exporter/merge_requests/1/diffs#229e10b19f8b27233d2301c8bb553b6bdd8e5b1a