>>>>> "Ian" == Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
Ian> For example, suppose upstream ship a timer unit. A Debian Ian> contributor wants to supply a patch to make the package use Ian> cron. You might very well want to use cron even with systemd; Ian> some people prefer cron's featureset. How is this supposed to Ian> be resolved in practice ? The non-systemd-using contributor of Ian> the cron job might which to simply add a dependency on cron and Ian> disable the timer unit by default. Or are the timer units Ian> supposed to be patched to be disabled when cron is installed ? Ian> It seems to me that these kind of technical details will need Ian> to be resolved via the policy process. These discussions are Ian> specific to each facility. We're agreed so far. Ian> In some cases we will want to Ian> simply provide an implementation of (perhaps a subset of) the Ian> systemd functionality. Ian> I think these decisions ought to be taken on a Ian> faciliy-by-facility basis. That's why my proposal sets out a Ian> set of criteria for judging whether a facility's interface Ian> ought to be adopted by Debian. Right. And the disagreement is whether the answer is a presumed yes you can use the facility or you need to go through the process ahead of time. I believe that my options accurately reflect the discussion I was trying to capture. The up-side of that is that it makes it easy to use new facilities. The down sides are the ones you've pointed out. As people find bugs they don't know how to solve, policy will have to catch up. But we're used to that. I think that you could find a few people who want to support both systemd timers and cron jobs together. And once you found a good way to do that, you could get it into policy. Your proposal blocks people from using the new facility until that discussion happens. Under Russ's option B and C, which I capture in my proposal, non-systemd users get degraded behavior until we agree on an approach and standardize it. In both cases we hopefully turn fights into bugs.