Re: Simple Init Diversity statement (search for seconds)
Dmitry Bogatov <KAction@disroot.org> writes:
> 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.
I'm not going to second this because it's not my own preferred choice, but
as with the options that Sam is proposing, I will vote this above further
discussion and I'm comfortable that it provides clear advice for Policy
(with some questions below).
>> 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.
Ah, yes, sorry. By "used" I meant "depended on." In other words,
packages may not require systemd-specific services unless the package is
of software that upstream has designed to only work with systemd. (They
can use them opportunistically if they're available.)
>> 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.
Okay, good, that makes the Policy implications clear.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: