Hi there, Preface: I'm not involved with the Debian project directly other than as a user. So while I personally have strong opinions when it comes to the init system, so far I have just followed the debate because I didn't feel it would be helpful to spam this bug with useless comments. That said, I have thought about the coupling issue for quite a while now and I firmly believe that the original L and T options are BOTH explicitly harmful (in different ways). For this reason, I feel the need to express my opinion on this subject. But after I have said my piece, unless there is a need for clarification on my side, I will walk back to the sidelines and continue to watch.
First of all, I do think there are legitimate concerns that lead to both the T and L options. On the one hand, the L text is clearly motivated by the worry that if a huge part of the Debian ecosystem (*cough* GNOME *cough*) suddenly depends on a specific init system (*cough* systemd *cough*) then the commitment to multiple init systems gets reduced to a farce. People might disagree about whether this is in reality going to become a problem, but I think the concern is legitimate. On the other hand, the T text seems to be motivated by the wish to not hamper progress when it comes to software, that the Debian project should not hold software back because of some ideological reasons. That said, I think both texts are problematic: L being far to extreme in its scope and T being far too toothless in the side sentence about "encouragement" when it comes to support for other init systems. The problem I have in this discussion is that only a few cases have been picked apart in detail, but the wider implications of these options have been mentioned in passing at best. So for this reason, I'd like to propose several different scenarios where the coupling question applies, so that the consequences of language used in the coupling question becomes clear. So let me draw up a couple of scenarios: (A) Someone writes a GUI for managing systemd that has the goal of providing access to as many features as possible, so that it really is tightly coupled to systemd in that sense. There is no way this could realistically be ported to other init systems. (Although a different software for e.g. upstart could be affected in the same way.) (B) Someone writes a GUI for accessing journald files on the hard drive. (C) Someone writes some kind of framework that depends on advanced systemd features, such as systemd-nspawn, to provide a novel technical solution. This software is new and not yet widely adopted. (Somewhere in the original discussion before all of the ballots, somebody mentioned something akin to this, I just don't feel it makes sense to invest the time to dig that up.) (D) Someone writes a daemon that currently only works with systemd, but a patch for including sysvinit and upstrart support is literally only 5 lines of code. (E) GNOME depends on logind interfaces and there is not working alternative logind (>=205) implementation available. (F) GNOME depends on logind interfaces and somebody stepped up and created a logind implementation for other init systems. (G) GNOME starts to depend on systemd as pid1 irrespective of logind. (H) Some software part of the default install set (which currently does not include GNOME but might again in the future) depends on systemd as PID1, either directly (see G) or indirectly via logind with no alternative implementation (see E). I think that both "L" and "T" options have undesirable consequences. (To clarify: I consider some of these to be undesirable for Jessie, not necessarily for later releases.) Let me start with "T": - Most serious case (H): If any software in the default install set depends on systemd, then this IMHO creates the de-facto situation that there really only is systemd support. Because if you can't switch the init system if you have a default set of software installed, saying that you support multiple init systems is a farce. Therefore, I definitely think that any resolution by the TC should include language that says that any software in the default install set should work with ALL supported init systems (with degraded operation being possible). So in the case of GNOME, if it continues to depend on logind (likely) and there doesn't happen to be a logind implementation that works with all the other init systems (unknown), then that should definitely disqualify GNOME from being made default desktop again. (OTOH, if there IS an alternative logind implementation at the point where this is decided, this doesn't stand in the way of GNOME becoming the default desktop again, but obviously it will also not make GNOME automatically the default desktop, that will depend on other things. ;-)) - Case (G): I don't think this is likely to happen for Jessie, but I do think this should be addressed. Since GNOME is one of the major desktops used by Debian users, I do see its position different from new, unadopted software. GNOME has a certain "market power", so if it starts depending on a specific init system (and by that I DON'T mean logind-type dependencies, I really mean explicit ones), I can understand why people feel that things are "forced upon" them. So I think this case should be avoided, at least for Jessie. Consider this akin to some kind of "antitrust law", i.e. if Debian is serious about commitment to multiple init systems for Jessie, a piece of software as major as GNOME should not depend *directly* on a single init system. (Transitive dependencies aka logind are a different story IMHO.) - Case (D): The "T" text encourages maintainers to include support for other init systems, but you could imagine a stubborn maintainer that refuses to even include a patch as trivial as described in that scenario. For this reason, I think the language could be made stronger at this point. But read my critique of "L" first, why I don't consider myself a supporter of "L" here, I just think that for this specific case, where support really is absolutely trivial, I think that stronger language might be needed. OTOH, you could argue that for these cases, the TC could override stubborn maintainers, so the encouragement might be enough to set a general policy. - Case (B): In that specific case, I actually think this is the same as case (D). Just because it reads journal files and has a nice GUI, I don't see any technical reason for the software to require systemd as PID1 (just that there won't be any new journal files generated in that case), and actually having something that reads journal files even on systems booted with another init might really be useful. [1] Now to the things I don't like about "L": - Case (A): This is one of the cases where I see "L" as the most harmful: Somebody writes a tool that improves upon a given init system, but is not part of it (as such, not falling under the exception made in "L"), and that can't be included in Debian. You might argue that it does indeed fall under the exception, but I don't see how you could think that, unless it is officially adopted by the systemd devs. This could actually lead to the really perverse situation that systemd is the default init, but the TC decides to forbid the inclusion of tools that make life with the default init easier for system administrators. - Case (C): Again, here I think "L" is actively harmful. Somebody writing a NEW piece of software that makes use of systemd's facilities to provide a new, awesome (in the author's eyes at least ;-)) technical solution to some problem, and then Debian saying that it's policy forbids to include it, because it might force people into using systemd, seems absurd to me. As I said above, when it came it to the GNOME issue, I would like to make a distinction between software with a certain "market share" that is already established, and software that is new (or for that matter, software that isn't new but in the past hasn't had that much of an install base). Now to the meat of the matter: logind, or transitive dependencies on interfaces provided by systemd, but at least in principle not necessarily tied to systemd. I think there is consensus in the TC about: - logind being a dependency is not a problem if there are multiple implementations of it, so that it works an all init systems. I think the difference in opinion boils down to: - who should have the onus to make logind work for !systemd? - Either the maintainers/devs of other init systems (This also means that if those people don't step up, GNOME will be allowed to indirectly depend on systemd because of this.) All the "T" people appear to take this position, but also Steve Langasek [2] - Or the GNOME maintainers (or whoever else wants to use logind) Ian Jackson sems to take that position [3], if I read his email correctly) - Or the systemd maintainers Personally, I think it's ridiculous that the systemd maintainers should do that (and I'm not sure anybody has really argued for that, even though Steve Langasek seems to think [2] that that is Ian Jackson's position in [3]). So you have the realistic choices of logind-using-software-maintainers vs. other-init-maintainers. I think I personally would go in the direction of other-init-maintainers. I don't see a violation of the "antitrust law" analogy I made above, simply because I think that in case of logind, other init systems are given the appropriate chance, and it is their problem if they decide not to take it. But I see that people can reasonably disagree here. To summarize: I think both "L" and "T" are both actively harmful. I have provided a list of scenarios (obviously not exhaustive, but probably good enough) which I think capture the different situations that might be affected by a decision on the coupling issue and given my opinion on those issues. What I think should be in any resolution is: - Default install set should NOT include anything that depends on a single init system (other than the tools coming with the default init system, obviously). - On the one hand, software packages with a wide install base should have a bit of an extra onus in that direct dependencies on a specific PID1 should be disallowed (indirect dependencies such as logind should be part of the vote), i.e. my "antitrust" analogy. - On the other hand, depending on systemd (or upstart or OpenRC, for that matter) should be allowed for software that is new or has never been "big" in the ecosystem. Otherwise, I think this will severely retard progress. See my discussion of cases (A) and (C). (Also, I don't think this should be restricted to default init, if somebody wants to write an awesome new solution that depends entirely on upstart or OpenRC, I think they should be free to do so.) - But if adding support for other init systems is trivial for a package (missing startup script etc.), there should be some kind of clear statement about that. - To summarize as a short sentence: allow dependencies when necessary, forbid them when possible. - The ballot itself should then be about the disagreement of who has the onus when it comes to transitive dependencies. Also, generally speaking (but I think there is already a rough consensus in the TC on that), I don't think it's wise to set policy for beyond Jessie NOW, since Jessie+1 will be released at least 3 years from now, and systemd itself is for example less than 4 years old (Lennart's "rethinking PID1" blog post is from April 2010), so a lot can happen in that time. Finally, there is the aspect of whether the TC should actually make a policy decision the coupling issue, I've heard claims that the question was not put before the TC and therefore the TC should only give advice, because it's not in its power to do otherwise. Correct my if I'm wrong, but wasn't bug #726763 [4] the straw that broke the camel's proverbial back that led to this discussion? I have to admit that all I know about Debian politics has come from reading the init system discussion (which is probably not the best introduction to it ;-)), but it appears to me that the coupling question is definitely something that the TC is allowed to address and probably actually SHOULD address. #727708 currently blocks the resolution of #726763 - so if you say that you are not going to rule on the coupling question, what is going to be TC's answer to #726763? With the current decision, which just affects the default init system, I don't see a clear unambiguous response to that bug from the TC. Just to give my 2ยข on that topic. Anyway, I hope that my thoughts on this matter were helpful and I do apologize for the length of this email, but since I have now said everything I wanted to say about this topic, I can now step back and stay out of it. Regards, Christian [1] Btw, I think systemd's own journalctl doesn't require systemd-as-PID1, so it might be a good idea to split the journalctl into a different package, so that people using other init systems could install it to read journal files generated on different systems. But this is just a tangent, so please don't focus on this... ;) [2] https://lists.debian.org/debian-ctte/2014/02/msg00308.html [3] https://lists.debian.org/debian-ctte/2014/02/msg00207.html [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726763 PS: Also note that this email represents my opinion given the constraints of the current Debian project and/or ecosystem, this does not represent my opinion of how I would design a Linux distribution from scratch if I had the time. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org