On Sun, Jul 14, 2019 at 07:23:31PM +0100, Simon McVittie wrote: > micro-httpd appears to be an example of this - I'm a bit surprised > there aren't more. Perhaps this indicates limitations in the infrastructure > around inetd services making it hard to implement "use systemd.socket(5) > under systemd or inetd otherwise"?
I'll note that it's a bit tricky even in the cron vs systemd.timer use case. That's what I was referring to when I said we had to go through some effort just to enable the "use cron" functionality, since we had to make sure that this was inhibited in the case where cron and systemd is enabled on the system. So requiring support of non-systemd ecosystems is in general, going to require extra testing. In the case of cron/systemd.timers, this means testing and/or careful code inspection to make sure the following cases work: * systemd && cron * systemd && !cron * !systemd && cron Support of non-systemd ecosystems is not going to be free, and some cases, it is not going to be fun, something which many have asserted should be something we should be striving for. The challenge is how do we develop the consensus to decide whether or not we force developers to pay this cost. And if we don't, is it better to just let this rot where we allow developers to violate current policy with a wink and a nudge until it's clear that we do have consensus? Or do we force them to do the work? Or do we somehow go through the pain and effort to try to determine what that consensus actually is? - Ted