Re: Proposal: Init Diversity
-----BEGIN PGP SIGNED MESSAGE-----
(Kurt, you can skip to "FAO KURT".)
Dmitry Bogatov writes ("Proposal: Init Diversity"):
> Here I formally propose following option, withdrawing any previous
> Being able to run Debian systems with init systems other than
> systemd continues to be value for the project. Package MUST work
> with pid1 != systemd, unless it was designed by upstream to work
> exclusively with systemd and no support for running without
> systemd is available.
> Software that uses systemd features non-conditionally should be
> considered as designed to work exclusively with systemd, but
> software that does just do not provide init.d should not. In
> case of doubt, explicit statement of upstream is definitive.
I have been having an email discussion with Dmitry about this. I find
this final paragraph unsatisfactory because it seems like it could
contradict the first part. As I wrote to Dmitry:
So, for example, suppose I find a daemon that unconditionally
expects the systemd daemon startup protocol. I write a patch to
make it able to work differently, with perhaps a command line option
or something. I submit it upstream, who say "no we are not
interested, this is designed to work exclusively with systemd". Am
I now to give up ? Debian need not take my patch.
Dmitry replied that this was not his intent, and explained his intent
to me. He said he would welcome a proposed amendment. I don't have
permission to quote his email, but I think I can capture his intent.
For now, I propose the following amendment: <=== FAO KURT
Delete the 2nd paragraph of Dmitry's proposal and replace with:
Software is not to be considered to be designed by upstream to
work exclusively with systemd, merely because upstream do not
provide, and/or will not accept, an init script.
I think the effect of this is:
* For software that merely needs an init script writing, an init
script MUST be provided (by the Debian maintainer, if necessary).
* For software that needs other patches writing, it is up to the
community to write patches for non-systemd support. The maintainer
does not need to write them but MUST accept them if they are
provided, because then "support for running with systemd is
* Software that is inextricably tied to systemd is permitted,
even though it only works with systemd as pid 1.
Dmitry's wording is less specific than mine about what happens if
non-systemd support patches are themselves RC-buggy but I think the
effect is the same. It would be unreasonable to say that "support for
running without system is available" if the "support" is RC-buggy.
I would appreciate it if others here would comment on my wording and
maybe help improve it. Dmitry's email latency means that he won't be
able to participate in the drafting as fully as ideal, so I would like
to make sure that he is offered the best possible wording.
For the avoidance of doubt, I am not trying to hijack Dmitry's
authority over his text. Please do not second my amendment. I am
hoping Dmitry will accept it (or some other similar improvement). If
Dmitry does not accept it I will withdraw it.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----