>>>>> "Matthew" == Matthew Vernon <matt...@debian.org> writes:
Matthew> On 15/12/2020 22:07, Sam Hartman wrote: >>> 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. Matthew> I find it surprising that, in a TC bug about (inter alia) Matthew> whether a dependency on libpam-systemd should be changed to Matthew> default-logind | logind i.e. to facilitate use of elogind Matthew> you appear to be saying that a GR text that talks about the Matthew> importance of "technologies such as elogind" should be Matthew> interpreted as meaning in effect that actually it isn't all Matthew> that important and network-manager should continue to have Matthew> effectively a systemd-only dependency. I'd like to be heard differently. I think that we should either decide that 1) NetworkManager should support elogind or 2) That we haven't seen enough development of alternatives to systemd and the project consensus on the GR has changed. Matthew> Not is it straightforwardly clear that "alternative init Matthew> systems" should in fact be interpreted to mean "alternative Matthew> init systems (but not sysvinit)". I'd like to be heard differently on this point too. I think that to the extent that people are doing things like adding support for service units, looking at ways of solving problems that motivated systemd in non systemd ways in the sysvinit ecosystem, that clearly counts as development of alternative init systems in the scope of the GR. I think that maintaining sysvinit for stable releases so that users can use it does not count as development of alternate init systems. I understand that several people in the project want to do that work. I'm not speaking against that work here, but I don't think you can use the GR as support for that work. Matthew> Nor is this a case of someone demanding that the Matthew> network-manager maintainer provide a sysvinit script nor Matthew> fix the bugs in an existing-but-broken one. Understood. I did suggest to Mark that he use that argument in arguing for maintaining the init script. As I mentioned policy process was not able to come to consensus on when to remove existing init scripts. --Sam