Re: Integration with systemd
On 10/31/19 11:30 PM, Russ Allbery wrote:
> Craig Small <csmall@dropbear.xyz> writes:
>> On Fri, 1 Nov 2019 at 08:27, Thomas Goirand <zigo@debian.org> wrote:
>
>>> However, this doesn't mean that anything non-systemd must implement all
>>> things that systemd does, or just die. It really doesn't make sense to
>>> tell that, for example, OpenRC should be forced into implementing a
>>> parser of .timer files, just because some maintainers wont care about
>>> cron jobs. These cron jobs could be maintained by those who care, just
>>> like with sysv-rc scripts, as a best-effort basis.
>
>> I think this, or something like this, is the policy update the project
>> needs. I think this is a fine option, but does the project as a whole
>> think so, or perhaps they do with some changes?
>
>> At the moment, my guess is most developers have no idea what the "right"
>> (e.g. what the project as a whole believe is right) solution for this.
>> Should I just use systemd support only? With sysvinit? If I get bug
>> reports about lack of support for one or the other how important is it?
>
> One variation on this that's worth at least thinking about, although
> perhaps it would be unworkable, is if those cron jobs, init scripts, and
> other similar components that need to be maintained could be shipped in
> their own Debian package.
>
> A lot of the process friction is in getting Debian maintainers to add this
> support to their packages. Even if all concerns about testing, support,
> and so forth go away, we know that this is still not painless (see, for
> instance, translations, where we do *reasonably* well but where
> translations can still sit in the BTS for extended periods of time). If
> it's possible to allow the people who are maintaining those files to
> upload them directly, it would remove that friction and process and might
> be easier to maintain.
While I very much like the idea of letting others do their work without
the maintainer to even notice to avoid frictions, I don' think adding
cron jobs in a separate package is the sensible solution.
Thomas Goirand (zigo)
Reply to: