[2019-11-14 17:15] Ian Jackson <ijackson@chiark.greenend.org.uk>
> Dmitry Bogatov writes ("Draft text on Init Systems GR"):
> > 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.
> We should clearly have something very simple like this on the ballot.
> I would strongly prefer this to some other plausible outcomes.
> However, I very much doubt that would command majority support. I
> think we can find a way to give everyone something tolerable.
> (elogind just migrated to testing.)
What do you mean "something tolerable"? In my opinion, my wording,
should it win, will protect 1300 daemons and their init scripts. I do
not see how you can relax wording without endangering this goal.
--
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.
Do you think it's ok in any case to remove init scripts. Let's say an upstream stops maintaining init scripts, and only ships unit files and says, oh all the distros we care about use systemd, so we're not going to bother to support init scripts any more. Assuming we already have an init script that works fine, can/should we remove it if the upstream no longer supports it? I guess my question is what does it mean to say "designed by upstream to work exclusively with systemd"? Is that ambiguous, or clear to everyone? I think we're going to hit grey areas, where upstreams may only test with systemd, but that it can be made to work with any init system.
Thanks,
Brian