The Grumpy Editor's guide to surviving the systemd debate [LWN.net]

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 8:45 UTC (Fri) by dlang (guest, #313)
In reply to: The Grumpy Editor's guide to surviving the systemd debate by anselm
Parent article: The Grumpy Editor's guide to surviving the systemd debate

> These people are free to submit patches to ensure that packages support the non-systemd init system of their choice, and package maintainers should be encouraged to take these on.

This is exactly what people are asking for as part of the Debian GR.

Too many people related to systemd have publicly stated that they consider supporting anything else to be a waste of time, and have talked about refusing patches that would allow for it to work without some of it's existing requirements or on non-linux systems because they think that the complication of the codebase is more of a problem than the benefit of supporting other systems.

to post comments

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 9:32 UTC (Fri) by anselm (subscriber, #2796) [Link]

Too many people related to systemd have publicly stated that they consider supporting anything else to be a waste of time

How many of these “too many people” are Debian developers?

You're re-stating the position of the systemd core team. This has precisely no bearing on what the maintainers of unrelated packages in Debian (those which might or might not come with upstream systemd or sysvinit support) ought to do. In particular, the systemd core team can't be compelled to do or not do something by Debian passing a GR. On the other hand, if package upstreams decide to avail themselves of systemd-specific features, it is unreasonable to expect that the Debian maintainers of such packages develop support for other init systems on the off-chance; it is much more reasonable to expect that those people who actually want to use the package in question with another init system should do the work, and that the Debian package maintainers simply propagate the outcome for the benefit of other users. (If the Debian package maintainers do decide that they don't mind doing the extra work themselves then that is of course also fine.) This appears to have worked in the GNOME case even in the absence of a GR.

Finally, taking outside patches for extra feature support isn't actually unusual in the Debian ecosystem, and it is safe to say that the vast majority of Debian developers – who are generally reasonable folks – will welcome that kind of assistance. If the Debian developer in charge of a package is adamantly opposed to accepting a sensible-looking and technically sound patch simply because they don't like what it does, there are ways of resolving such impasses that do not involve project-wide GRs. So far in the systemd case this hasn't happened; we have had the opposite case where a maintainer didn't want to take on a patch that contributed systemd support for their package because they didn't like systemd – but as I said there are easier ways to sort this out.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 18:57 UTC (Fri) by rahvin (guest, #16953) [Link] (6 responses)

No what they are asking for is that Debian maintainers be forced to support other init's or the software they maintain will be removed after someone files a bug report about the lack of support. It's completely against the Debian constitution and contrary to the principles of the entire project.

Every constitutional grouping of people eventually faces a challenge where a group of constituents eventually tries to get a rule passed through one of the rule making bodies or by direct vote that is directly contrary to the basic rules of the constitution. Not all of them survive this attempt. I fear for Debian when one group of people tries to force another to do something.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 19:06 UTC (Fri) by mgb (guest, #3226) [Link] (5 responses)

Deliberately breaking previously working software in order to force systemd to be installed is contrary to Debian's Social Contract.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 19:10 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

the problem is in evaluating intent

is making Gnome depend on systemd done to force systemd to be installed? because the person doing it didn't realize they did it? or because it's the only way to get something done that they think is more important than running on systems without systemd?

patches and text communications are a horrible way to try and figure out what the intent of the person was, especially if there is any suspicion that they are not being open about their intent

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 28, 2014 6:47 UTC (Fri) by blujay (guest, #39961) [Link]

Isn't the end result more important than someone's intentions?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 19:49 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (2 responses)

s/breaking/changing/

This is really really boring now.

https://mail.gnome.org/archives/distributor-list/2012-Jan...

Anyone serious about putting in effort of forking now over the systemd dep that has come up through logind as a replacement for consolekit, could have really made a difference in 2012 when consolekit became a dead project upstream. You so could have made a positive impact for your chosen cause in 2012. Could have really made a difference and made sure consolekit was still a viable upstream project...in 2012.

Back in 2012, there was an expectation that people interested in consolekit, specifically Ubuntu, would be stepping up forking it and maintaining the fork. That anticipated fork didn't actually happen and Ubuntu actually moved to logind. No idea why Ubuntu didn't stick with CK. There's no real discussion on that.

Seems a bit of wasted energy to get mad 2 years later about projects choosing to no longer depend exclusively on an unmaintained codebase, and have moved on to use something that is actively maintained.

Would you like to borrow my time machine and go back to 2012 and fork consolekit when it was a timely option?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 20:26 UTC (Fri) by mgb (guest, #3226) [Link] (1 responses)

> Would you like to borrow my time machine and go back to 2012 and fork consolekit when it was a timely option?

I think you must be talking about Fedora which is indeed a lost cause.

Debian still has consolekit.

Meanwhile Erik Koegel forked consolekit2 so Debian will not have to continue maintaining FreeDesktop's software.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 21:23 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

No my timemachine doesn't run fedora.. it runs android...being from the future and all.

The fact that Debian still has consolekit as a package doesn't change the fact that it has a dead and unmaintained upstream and other maintained projects should be relying on it.

And honestly it doesn't look to be actively maintained as a package in debian either as there are provided patches sitting in the debian bug tracker for years now.

yes indeed consolekit2 is an interesting development. Officially made public in October 2014, commit log suggests work started on it in feb 2014. Either way 2+ years after upstream died to announce the fork. Its existence now does not change the decision making leading up to October prior to it being known to exist. And it too late to make the jesse freeze without special consideration. So it doesn't even really change the situation for maintainers in the jessie release timescale either.

Really too bad it took 2 years for that fork announcement to happen. One has to wonder on the delay there. Like maybe if Debian had announced the intent to switch to systemd earlier, the fork would have happened earlier as well and there wouldn't have been a 2 year delay like this.

I mean seriously the consolekit2 fork was almost too late, even projects being run by maintainers who have previously voiced concern over systemd dependency. For example Lightdm was ready to drop CK support this month because of a lack of a maintained CK codebase.

Ref:
http://lists.freedesktop.org/archives/lightdm/2014-Novemb...

http://lists.freedesktop.org/archives/lightdm/2014-Novemb...

Once consolekit2 shows up in deb packaging, that will be an interesting discussion.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 12:32 UTC (Sat) by ms_43 (subscriber, #99293) [Link]

The systemd approach to OS portability is similar to the OpenSSH project... see my earlier comment on this:

https://lwn.net/Articles/620747/