Choice: Affirm Init Diversity
Being able to run Debian systems with init systems other than
systemd continues to be value for the project. Package not
working with pid1 != systemd is RC bug, unless it was designed
by upstream to work exclusively with systemd.Since Sam refused to add my option to ballot, hereby I call for seconds. [2019-11-13 19:03] Russ Allbery <r...@debian.org> > Apologies for the duplicate -- I completely spaced on leaving you in > the Cc line on the first reply. Other folks, please reply to this > message instead and keep Dmitry in the Cc line. > > Dmitry Bogatov <kact...@disroot.org> writes: > > > So, here is my rewording, much simplier and shorter. > > > Choice 1: Affirm Init Diversity > > > > Being able to run Debian systems with init systems other than > > systemd continues to be value for the project. Package not > > working with pid1 != systemd is RC bug, unless it was designed > > by upstream to work exclusively with systemd. > > > Missing init script for package with daemon is RC bug. > > The second and third sentences contradict each other. I think you mean > for the second sentence to be overriding, meaning that a daemon whose > upstream authors only support systemd can be packaged without an init > script. But could you confirm? (And rephrase if you end up offering this > as an amendment?) Yes, you are correct. We can drop third sentence at all, and have it as simple as what listed at top of mail. > The implication I would take as Policy editor from this option winning > is that any systemd service that is not supported by (all?) other init > systems in Debian must not be used, except in packages whose upstreams > only support systemd. Packages whose upstreams only support systemd > may use those facilities freely. I do not see how it follows from my wording. If under sysvinit server is started on boot, and under systemd it is started on first request (socket activation), that is fine as long in both cases servers perform same. > BTW, if this option passed, I believe the implication would also be > that all GNOME ecosystem packages can drop all sysvinit support and > that no maintainers of packages designed upstream to work with logind > are under any obligation to support elogind. Is that what you intend? I am fine with these consequences. This is my personal opinion, and do not represent opinions of other sysvinit maintainers. > These questions aren't intended to be confrontational and they're not > trick questions. I plan on trying to turn the results of this GR into > Policy language, and these are the issues that will come up. I'm pushing > for this GR to be as explicit and unambiguous about its consequences as > possible. Yes, I understand. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
pgpLYfIGK2szl.pgp
Description: PGP signature
