Christian Seiler <christ...@iwakd.de> writes: > 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.
Well, the T language wasn't written by me, but I should clarify that's not what I'm trying to say in my proposals. I think Debian should do lots of things for ideological reasons. One of the pieces of Debian ideology that matters a great deal to me is that we should trust our package maintainers to choose how to package the software they maintain, and trust their judgement about the approach that provides the best, most high-quality, and most integrated experience for our users. In other words, what I want to do is defer to package maintainers, who are, after all, experts in the packaging of their software, to make good decisions. The TC should only get involved where there are irreconcilable conflicts about how to do this, or when the project asks us for guidance on how to achieve distribution-wide integration. I feel like an argument could be made that the project has asked us for advice on this (although I think a good argument could be made that the project has *not*, which is Keith's point). I'm trying to express that advice while continuing to recognize and respect the fact that Debian defers, in nearly every case, to the informed technical judgement of the packager or packaging team, and generally tries to address most conflicts by enabling the parallel packaging of software with different approaches rather than choosing a single winner and rejecting all other "competing" packages. I'm also trying to respect the core foundational value of Debian that volunteers get to work on what they choose to work on, and no body in Debian has the authority to order people around. I found your specific cases a useful clarifying exercise to lay out how I think about this, so let me respond to each of them: > (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.) This clearly should depend on systemd and should be allowed. > (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. > (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.) This clearly should depend on systemd and should be allowed. > (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. Assuming that this is a new package not previously in Debian, and after systemd has become the default init system, I think it should be fine to introduce this package with a dependency on systemd until such time as someone actually writes and tests that patch. Once that patch is written and tested and submitted, the maintainer should incorporate it and drop the dependency. (Constitutionally, I don't think the TC should require maintainers to do this in advance, but if this actually got escalated all the way to the TC as a maintainer override, something that I really hope would never happen and I see no reason to believe would happen, I would be baffled by why the maintainer wouldn't include such support.) > (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 parenthetical.) I think this should be fine. But this is a controversial case that we have strong reasons to believe won't actually arise, so it's not clear whether there's any need to argue about my position on it. > (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. > (G) GNOME starts to depend on systemd as pid1 irrespective of logind. There doesn't seem to be any technical reason why this would be necessary, so I think this is inappropriate. I believe that's also the opinion of the GNOME maintainers; in other words, they have no intention of doing this. > (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). There don't appear to be any technical reasons why this would be necessary, so I think this would be inappropriate for the same reason. > 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. ;-)) The GNOME part has been discussed at length here. I'm fairly sure that the situation we'll end up with is that GNOME will depend on the disjunction of the available logind implementations, and Steve is extremely confident that logind will be available under sysvinit for jessie. 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. > - Case (G): I don't think this is likely to happen for Jessie, but I > do think this should be addressed. In general, I part company with you at this point. If something isn't likely to happen, I *don't* think it should be addressed. In fact, I think it *should not* be addressed. We have enough immediate issues; let's not borrow trouble by both addressing things that are unlikely and then lecturing our developers about how to handle cases that they're probably quite capable of handling themselves. > - 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. In general, my feeling is that Debian maintainers do not have to be carefully programmed to do exactly what the Technical Committee thinks they should do. The default should be to allow maintainers to use their own technical judgement. If maintainers do something particularly bad or contrary to overall project goals, we can deal with that when it happens and we have mechanisms to do so, but treating maintainers like they will do that proactively is paternalistic and unnecessary. I'm going to skip through more of the analysis here, and just walk through your list of things that you think should be in any resolution: > 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). The default install set is determined by the installer team. I don't currently see any need for the TC to get involved in their work, and I don't think the d-i team has asked us to do so. I think they are quite capable of weighing these issues and making appropriate decisions about the default install set, or expressing their concerns to other package maintainers. > - 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. In general, I agree with this, and I also think that the maintainers of such packages would generally agree with this, because of the impact that they have on the distribution. However, they have to balance this concern against the fact that some of those software packages (such as desktop environments in general) also have the most need and demand for advanced facilities. These packages often stress the limits of the capabilities of the system in ways that the "average" software package does not. That balance is difficult and tricky, and I think our DE maintainers by and large do an excellent job at this. I have a strong preference to letting them go about their work. 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. If there are other issues like this, I think the DE maintainers and the init system maintainers and possibly the porters should talk it over, and if they need us to get involved, we'll always be here. But most of these issues can be worked out amicably without any need for TC involvement. > - 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.) I agree with this. > - 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. I agree with this as well. > - To summarize as a short sentence: allow dependencies when necessary, > forbid them when possible. I don't like the idea of the TC forbidding things at this point, but I think that's a good summary of what I think maintainers should do (and I think what maintainers will do). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
