Web lists-archives.com

Re: Debian Buster release to partially drop non-systemd support




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