The Debian init system general resolution returns

Posted Oct 17, 2014 21:04 UTC (Fri) by mpr22 (subscriber, #60784)
In reply to: The Debian init system general resolution returns by ctpm
Parent article: The Debian init system general resolution returns

The sensible option would be to, at least, give users the *choice* of init system.

A sensible option which Debian developers have, in fact, already made happen while various people rage and flame about systemd for reasons varying from the thoughtful and well-reasoned to the spiteful to the downright paranoid.

Debian jessie has multiple init systems available right now while it is still testing, and when it is released as stable it will have multiple supported init systems, and upgrading from wheezy to jessie without changing init systems is a thing that works now in testing and will work at stable release.

The Debian init system general resolution returns

Posted Oct 17, 2014 22:23 UTC (Fri) by ctpm (guest, #35884) [Link] (3 responses)

>Debian jessie has multiple init systems available right now while it is still testing, and when it is released as stable it will have multiple supported init systems, and upgrading from wheezy to jessie without changing init systems is a thing that works now in testing and will work at stable release.

Well, yes, but that multiple init system support is worthless *if* the maintainer of one of the packages you wish to install makes it depend on a _specific_ init system, out of the ones supported. Then you may be hosed.

So, AFAICS, Ian's proposal makes total sense in that it prevents packages from arbitrarily depending on specific init systems left and right, but instead work with every one (within reasonable conditions, as described in the proposal). This too seems pretty obvious and well-reasoned on his part.

The Debian init system general resolution returns

Posted Oct 18, 2014 0:39 UTC (Sat) by rahvin (guest, #16953) [Link]

And it does so by telling package maintainers, who according to the Debian constitution are granted absolute decision making power on the package they maintain, are not allowed to oppose or interfere with a patch regarding init systems. And includes a process by which anyone can run through and submit bug reports on any software with a hard dependency on systemd which will either force the forking of the package to remove that dependency or the packages removal from Debian.

That is not sensible policy. It's an authoritarian nightmare.

The Debian init system general resolution returns

Posted Oct 18, 2014 10:47 UTC (Sat) by farnz (subscriber, #17727) [Link] (1 responses)

So, serious question time. Assume I'm an upstream developer of a desktop environment; I need a mechanism to allow an unprivileged user to power down their system at the close of their working day, except where the system administrator has chosen to prevent that from happening (e.g. so that they can install updates).

My choices are:

Implement ConsoleKit support; ConsoleKit is unsupported, probably buggy, and no-one's working on fixing it.
Implement my own mechanism, and hope that I can persuade other developers to adopt my mechanism. Note that I'm not necessarily a big name in the community, so it's unlikely that (e.g.) apt will implement inhibit support using my mechanism.
Depend on the org.freedesktop.login1.Manager interface, currently only implemented by systemd, but documented well enough for someone else to implement it too. This is supported on multiple Linux distros (even Ubuntu implements it on top of upstart), and provides the features I want. It also has an active upstream fixing bugs.

In your view, which of the three options should I take? If option 3, would this GR oblige someone wanting to package my DE for Debian to reimplement the DBus interface for another init system, or not?

Note too that at least on Fedora, if not other distros as well (Fedora happens to be what I use), option 3 integrates nicely with the package manager - if the sysadmin logs in remotely and runs "yum", the package manager will inhibit shutdown for the duration of the operation.

The Debian init system general resolution returns

Posted Oct 18, 2014 13:23 UTC (Sat) by HelloWorld (guest, #56129) [Link]

Well, there's always option 4: use org.freedesktop.login1.Manager and do nothing if you can't find it. Which will of course result in brokenness and is exactly where Debian will head if this GR succeeds.