Bug#727708: multiple init systems - formal resolution proposal
On Sat, Feb 01, 2014 at 11:25:01AM -0500, Steve Langasek wrote:
> Josselin has asserted not only that he considers systemd-as-init a hard
> dependency for GNOME in jessie, but that he expects the release team to side
> with him over the Technical Committee if the TC does not agree with him.
> This is unconscionable, given that there are two very straightforward and
> obvious technical solutions to this problem:
>
> - split the systemd package (as previously discussed) into separate
> binaries, for the init system vs. the dbus interfaces, and have GNOME
> depend on the latter
I the light of what I know about this issue from the systemd side,
splitting the package into multiple independent components is much
harder than it looks. For one, logind used to call into PID1 for
shutdown/suspend/... but not it'll also attempt to start the user
manager and tell PID1 to manage resource limits. I don't suppose
systemd-shim is ready for that. Second, logind uses journald for
logging. This actually is also an issue for gnome: gdm now logs to the
journal, which makes debugging gdm initialization issues so much
easier. Recently patches which redirect X logs to the journal have
been accepted (even if not merged yet afaik) [1]. The hypothethical
systemd-logind package would not only use a different provider of the
most crucial services, but would also lose existing logging
mechanism. Apart from that, loginctl communicates with PID1 to show
cgroup information... Put in a lot of work to build a more brittle
system and lose functionality? Even if it might have been easier for
old systemd versions, the components are now fairly tightly coupled.
Even if such a split could be done with enough man-hours thrown at it,
I think it's obvious why Joss and other people who use systemd aren't
thrilled about the prospect, especially with #727708 undecided.
> - have the systemd package declare one or more virtual packages via
> Provides:, which GNOME packages depend on and one or more alternative
> implementations may also provide.
As argued elsewhere, since there are no alternative providers, this
would amount to a hard dependency on systemd, which gnome is not allowed
to do.
Josselin's stance, even if strongly expressed, seems accurate.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=722889
Reply to: