Adrian Bunk <b...@stusta.de> writes: > On Sat, Jan 18, 2014 at 09:45:35AM -0800, Russ Allbery wrote:
>> If software that people want to package for Debian is deeply entangled >> in one init system (that is supported in Debian), for good or for ill, >> regardless of what one might think of the decisions made by upstream >> that created that situation, I think it's going rather far to require >> the Debian package maintainers to port it to different init systems in >> order to get (or keep) their package in Debian. I have a very hard >> time defending that position. > So in the hypothetical case that systemd upstream decides to make udev > hard depend on systemd being pid 1, would you even defend that such a > change could go into jessie if the CTTE decision was that Debian should > support multiple init systems? It would, of course, depend on *why* they made that decision, but at least on the surface that seems like it would prevent us from either supporting multiple init systems or having a reasonable upgrade from sysvinit. Those would both be significant drawbacks, so I think in such a situation we should look for alternatives. (And I know the udev maintainer really wants to require a modern init system -- that was one of the messages that set off this discussion -- but I do think it would be worthwhile waiting until after jessie to take that step.) You may be noticing a theme here: I'm refusing to take hard positions, in advance, on theoretical future possibilities. I think that's part of the responsibility of the Technical Committee. See 6.3.6: Technical Committee makes decisions only as last resort. The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it. I believe the spirit of that provision includes not borrowing trouble for ourselves by making definitive statements about future events that may or may not happen. Remember, the context of this discussion is around whether the Technical Committee, assuming that we choose systemd as a default, will require that all software in Debian that's part of the jessie release work with sysvinit as well. I'm pointing out edge cases and possible drawbacks to making a firm and sweeping statement without knowing, in advance, *why* some piece of software doesn't work with sysvinit. Other people have pointed out other cases, such as software that was never part of previous releases and hence doesn't pose upgrade issues. > We are in full agreement on that. > And my point on top of that is that if the CTTE decsion would be that > Debian should support multiple init systems, but it does not set a > policy limiting strictly what hard dependencies on systemd are allowed, > then it would be better if the CTTE would rule that Debian should > support only systemd since that's what would anyway happen in practice > through package dependencies pretty soon. And yet there are still people who use Debian without udev (or at least I think there is based on debian-devel discussion). Why go out of our way to tell those people to go away? There is a natural process here, where rarely-used configurations slowly stop working and people eventually decide not to bother to keep them working and move on to other things. Eventually, they may acquire RC bugs that no one wants to fix and be dropped, or the package maintenance team may decide that they just can't support the configuration any more, make a public call for people to step forward and maintain it, and, when that call isn't answered, drop support. The drawback of trying to short-circuit that process is that it's quite easy to guess wrong and decide to proactively drop support for something that turns out to not be that hard to continue to support, or that someone else wants to support and is willing to do all the work to support. I'd rather leave it to the expert analysis of the people directly involved, and don't want to skip past the courtesy of inviting people to find a way to fix the problem if they care about it. To take another example, do you think the Technical Committee should have said that file-rc is not supported? I don't see why we should make that sort of proactive statement. Yes, it doesn't work very well, and has some problems, but people have still been using it, and people are still willing to fix problems with it, so why go out of our way to tell those people to stop? In other words, I would rather be clear about what we consider to be the primary technical direction, and the core functionality that we should try to support, and let the long tail and personal projects take care of themselves. Some of them will fade away, some of them will putter along in the background without hurting anyone, and we may be quite surprised by one of them becoming a huge asset to the project later on. That's why I like the framing of this discussion as deciding the *default*. > If Debian wants to support multiple init systems and wants to continue > supporting non-Linux ports, then Debian's policy must force Debian > maintainers to put pressure on their upstreams to keep support for > non-systemd systems and for non-Linux kernels. Sort of. But I don't think that level of pressure is necessarily higher than the pressure we've been putting on upstream to support Hurd for years, which has amounted to a small stream of patches that are generally unobjectionable. -- 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