Bug#727708: init system coupling etc.
Le jeudi 13 février 2014 à 23:47 -0800, Russ Allbery a écrit :
> > (B) Someone writes a GUI for accessing journald files on the hard drive.
> Depending on how this is written, it may depend on the package providing
> journalctl or it may depend on some shared library that implements the
> journal reading code, or it might even have no dependencies at all if it
> implements the journal reading code itself.
This is not a hypothetical case. It exists, and it uses journald
directly. The software will not start if systemd is not PID 1. Note that
this is part of what we’d like to put in the gnome metapackage, so
forbidding this has real impact on real packages for jessie.
> > (E) GNOME depends on logind interfaces and there is not working
> > alternative logind (>=205) implementation available.
> (I don't know of any reason why GNOME would specifically need to depend on
> a post-205 logind at this point, so I'm replying to this without the
This will certainly happen one day or another, but probably not for
This (not isolated) case raises the point of package-level management of
non-library interfaces, with versions. We might need to set a policy on
this kind of cases. For example, should we generalize situations such
* systemd-sysv Provides: systemd204, systemd207, …
* foo Depends: systemd-sysv (>= 204) | systemd204
> > (F) GNOME depends on logind interfaces and somebody stepped up and
> > created a logind implementation for other init systems.
> In this case, I think GNOME should allow either implementation to satisfy
> its dependency. I think that's uncontroversial across the board,
> including with the GNOME maintainers.
This is indeed uncontroversial, except for the part that the non-systemd
case would be unsupported from the GNOME side.
I’m just not seeing this happening (see at the bottom).
> It's possible that, in the long, long run, GNOME will want to depend on
> systemd to use systemd for session management, but it's already been clear
> on this thread that this won't happen for jessie, and it's not at all
> clear whether this will ever be necessary or whether there will always be
> a fallback available. It is obvious, at least as I understand it, that
> this won't be necessary or something anyone is considering for jessie.
It has already been made clear that this WILL happen for jessie, but
that a fallback (either in the same package or another one) can be made
> We have one specific issue around logind that is likely to affect GNOME
> and KDE and possibly others, and we've talked about the solutions in
> detail and Steve is confident that we can solve this issue for sysvinit
> for jessie.
The only available solution so far involves keeping a systemd 204
package, which will not happen. With systemd as the default init system,
the systemd maintainers will try to have the latest version integrated.
So either Steve and his cronies commit to maintain a separate systemd204
package (with all the switching issues that scenario involves), or they
deliver their so-far vaporware to work over systemd >= 205. Or it just
doesn’t work, which is what will probably happen.
In all cases, it is unacceptable to put the burden of implementing
logind on non-systemd systems on maintainers of packages that just need
the logind interfaces. If it is not available, software such as gdm3
will depend, directly or indirectly, on systemd as PID 1, and that will
(For non-Linux ports, the old ConsoleKit code will be enabled instead,
but users should not expect this to work at all.)
.''`. Josselin Mouette
: :' :