I had a great discussion with Mark Hindley about this issue a few months ago. I'd like to summarize what I said in that discussion as input to the TC.
But I'd also like to start out by reminding us all what we said in the GR text that we agreed to. As one of the contributors to that text, you might either think I'm in a good or a bad position to interpret it, depending on how you think about such things. I think it's clear I've thought about the problem space somewhat. >However, Debian remains an environment where developers and users can >explore and develop alternate init systems and alternatives to systemd >features. Those interested in exploring such alternatives need to >provide the necessary development and packaging resources to do that >work. Technologies such as elogind that facilitate exploring >alternatives while running software that depends on some systemd >interfaces remain important to Debian. It is important that the >project support the efforts of developers working on such technologies >where there is overlap between these technologies and the rest of the >project, for example by reviewing patches and participating in >discussions in a timely manner. We did not say in that GR that we were interested in supporting ongoing development of sysvinit. Certainly, in my advocacy post for the winning option, I argued that didn't make sense to me. We said only that we were interested in the facilities to allow people to develop alternate init systems. (We did not say we wanted to throw sysvinit away either, but the project did not commit in the GR to interest in sysvinit). We also said: >The Debian project recognizes that systemd service units are the >preferred configuration for describing how to start a daemon/service. That has been further codified in policy as I'll discuss below. I'd think that by the time an alternate init system becomes a plausible general purpose alternative to systemd, it needs to support service units. We also said: Using its power under Constitution section 4.1 (5), the project issues >the following statement describing our current position on Init >systems, Init system diversity, and the use of systemd facilities. This >statement describes the position of the project at the time it is >adopted. That position may evolve as time passes without the need to >resort to future general resolutions. So, the consensus can evolve as we watch what people do, and we see how valuable development of alternate init systems is. Personally, I think that an important consideration would be how much actual development of init systems are we seeing vs how much maintenance of existing init systems are we seeing. If we're seeing people who are actively working to solve the problems that made systemd attractive in other ways, writing new code, that sort of thing, I'd hope that we would support that work and get it unblocked. If all we're seeing is maintenance of the same existing init systems, my personal view is that's not what the winning GR option was about. Other things we did not say. We didn't say other init systems would be in bullseye (nor did we say they would not). In my mind, we committed to allowing developers to experiment, not at this time to making any particular init system beyond systemd ready for release. Now, presumably, if someone comes up with some great new init system that solves the problems that makes systemd attractive over sysvinit to a number of users in ways that are different/better, we'd probably like to include it in a release. If sysvinit's users and maintainers can get it ready to be releasable we'd probably like to do that, although I don't think the GR applies to that work so much as the work necessary to allow development to continue. I'll close with my comments to Mark, which touch on how this all interacts with policy as I understand it. I'm mostly going to avoid value judgments and focus on my understanding of what Debian decided in the vote and what our policy is, and try and help you accomplish your goals under that set of constraints. The short of it is that I think we decided that init scripts are purely optionalal. As a consequence, I think that any alternate init system needs to handle service units, or some significant subset of them, to be useful. But see below. I think there are two issues here. I actually think that you have a reasonably good case for escalating the NetworkManager support for the virtual logind packages. In particular, our GR said we were interested in facilitating that work. So, I think it would be reasonable to ask what's going on with that and ask for help trying to work through that. The init script case is more problematic. You don't explain why NetworkManager should have an init script, and the current thinking in Debian policy is that were it a new package, it probably should not. Quoting section 9.3.1 of policy: Packages that include system services should include "systemd" service units to start or stop those services. See *systemd.service(5)* for details on the syntax of a service unit file. In the common case that a package includes a single system service, the service unit should have the same name as the package plus the ".service" extension. If the package does not include a service unit (if, for example, no one has yet written one), including an init script, as described below, to start the service is encouraged. Packages including a service unit may optionally include an init script to support other init systems. ---------------------------------------- So, wishlist bug for an init script seems about right, and "don't want to maintain and test both," seems like an entirely reasonable justification for closing that bug as wontfix under the GR text and under the policy amendments that reflect that. The policy discussion frowned on removing initscripts without careful consideration because it could potentially break existing systems. However, the policy process did not come to consensus on that. So, I think you have two approaches. First, if the removal of the init script is breaking existing systems, I think it's reasonable to engage on that front. But a maintainer might reasonably ask you to engage in an attempt to get to an end state of no init script while managing the breakage. So, for example postinst to detect/warn about situations, documentation in a news file, etc. You could also potentially engage on debian-policy and come up with recommendations for how to avoid breakage in existing packages when looking at init scripts and considering removing them. And then if you got consensus on such a change, engage with the NetworkManager maintainer. There's one other approach. If there's some reason that NetworkManager needs an init script more than other things, that might be worth discussing. But I think our thinking is that especially for simple init scripts, service units are the new init script, and anything that comes along is going to have to deal with that. Again, very happy to work through this with you, with the understanding that options may be limited given what we decided.
signature.asc
Description: PGP signature