Bug#727708: multiple init systems - formal resolution proposal
Adrian Bunk <firstname.lastname@example.org> writes:
> On Wed, Jan 29, 2014 at 07:17:29PM +0100, Josselin Mouette wrote:
>> Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit :
>>> What *basic functionality* exactly is missing in GNOME 3.10 without
>>> Note that I am not referring to bugs that are not yet sorted out like
>>> * Switch from consolekit to systemd-logind sessions. For some reason
>>> gnome-shell 3.10 unlocking fails with consolekit...
>>> 3 months ago in gdm3 - I am referring to basic functionality that is
>>> simply missing in GNOME 3.10 without logind.
>> You have the answer to your own question above. Unlocking the screen
>> sounds like pretty basic functionality.
> Your statement was
> I also have to insist that GNOME 3.10+ *needs* a working logind even for
> basic functionality
> Are you saying that there are only some bugs to get sorted out for using
> GNOME 3.10 without logind, or is there a fundamental technical reason
> why some *basic functionality* (which?) cannot be made working in
> GNOME 3.10 without logind?
I'm still wondering if maybe there's just a communication failure here, so
let me try one more round.
My understanding of what Josselin is saying is that GNOME's ConsoleKit
support is effectively unmaintained and unsupported upstream, as is
ConsoleKit itself. The consequences of that are starting to show in a
variety of unfixed bugs.
In one sense, that's "just" bugs to be sorted out. However, they're
upstream bugs in code that upstream appears to no longer be interested in
supporting, and they're bugs that the Debian GNOME maintainers are
unenthused about trying to fix, since that would effectively require
taking over maintenance of the ConsoleKit code upstream. (Not to mention
that the logind code path appears to be technically much better and have a
much stronger future, so it's hard to get motivated to work on the
In other words, they're bugs with no resources currently assigned. Note
that things like screen lock have security implications, so the jessie
stable lifetime *is* important for this code. Maintaining it properly
would require confidence that we would be able to identify and fix
security issues in the GNOME code and in ConsoleKit through the jessie
Obviously, if resources appear, that changes the situation, but I think
the GNOME maintainers are understandably wary of such approaches as
someone taking a week and fixing all the currently known bugs and then
moving on to other things, since their expectation is that, given the
situation, new bugs and new issues will continue to arise. The code
really needs an ongoing maintainer with a good upstream relationship who
can get the fixes and support incorporated upstream for it to remain
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>