Processed: retitle 975075 to tech-ctte: Should NetworkManager support elogind?
Processing commands for cont...@bugs.debian.org: > retitle 975075 tech-ctte: Should NetworkManager support elogind? Bug #975075 [tech-ctte] Should NetworkManager support elogind? Changed Bug title to 'tech-ctte: Should NetworkManager support elogind?' from 'Should NetworkManager support elogind?'. > thanks Stopping processing here. Please contact me if you need assistance. -- 975075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: retitle 975075 to Should NetworkManager support elogind?
Processing commands for cont...@bugs.debian.org: > retitle 975075 Should NetworkManager support elogind? Bug #975075 [tech-ctte] tech-ctte: Should maintainers be able to block init compatibility changes? Changed Bug title to 'Should NetworkManager support elogind?' from 'tech-ctte: Should maintainers be able to block init compatibility changes?'. > thanks Stopping processing here. Please contact me if you need assistance. -- 975075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Elana, Thanks for passing this on. On Mon, Dec 21, 2020 at 03:36:45PM -0800, Elana Hashman wrote: > Less than 1% of users are installing sysvinit-core, with a steady > downward trend.[1] I accept that the number of users is small, although the figures referenced omit users of openrc and runit. It is also worth noting that is is currently moderately difficult to switch away from systemd to another init. Suggestions of ways of making this more user friendly have been rejected[1]. In this case using popcon as definitive evidence of the actual demand seems questionable. > elogind is very difficult to support in its current state (see the > following bugs: [2] [3] [4] [5]), which is why Michael does not want to > maintain support for it. He may not want to, but I still see no technical or other reason why this should be blocked: elogind has been in the archive since buster; it is specifically mentioned in the winning GR option as technology to explore; the logind and default-logind virtual packages have been in the Policy since version 4.4.0 of July 2019 My assessment of the bugs that Michael references is rather different. - #923244 was resolved in February 2019 and whilst I realise that Michael remains unhappy with the way that resolution was achieved, the solution works for both non-systemd users and systemd users and I am not aware of any regressions. - #934491 was closed after being fixed by the resolution of #935910 in apt. - #959920 was really about systemctl providing systemd, and only indirectly related to elogind (which conflicts with systemd, as you would expect). - #968379 was resolved with the latest upstream release of elogind. Although elogind inclusion and support was controversial and hard-won, these specific issues have been resolved. Making use of the default-logind and logind virtual packages actually makes elogind rather easy to support. Mark [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935304
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Matthew writes: > * We've talked about the burden already; there are people willing and > able to help with this, and that offer remains good, be that by > providing patches, MRs, help with bug reports on non-systemd systems, > NMUs, or some other mechanism that Michael would prefer I think that it is worth mentioning, in this context, the burden on the other side. That is, the burden Debian places on those who want to "explore alternatives to systemd", as the GR puts it. The non-systemd community has suffered many unexplained or poorly-explained deletions of working functionality, and several other kinds of blockages. Each time we need very careful escalation to the DPL and the TC etc. [1] This continual fight to not have working things deleted (or broken without good reason) is *much* more work than we are asking of the maintainers of core packages like network-manager. The opposition we face, and the consequential burden of constant emotional and political attrition is *the only real impediment* to having really good support for alternative init systems in Debian. It is also a drain on the energy of the people who would otherwise be developing and integrating alternatives to both systemd and sysvinit. Ian. -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hi, On 21/12/2020 23:36, Elana Hashman wrote: The maintainer, Michael Biebl, reached out to the tech-ctte privately. I have summarized his reasoning for why he dropped support for elogind and the init script that prompted this bug: Thanks. There's little point trying to have this discussion with Michael by proxy, I suspect, but I thought I would make a couple of observations on what he says; I will try and not repeat myself too much, although he does raise things that have already come up in this bug. * While we have largely talked about sysvinit here, the issues here do relate to other init systems - elogind integration is useful for all non-systemd inits * I appreciate that there is a tension between maximally integrating systemd-specific features into the distribution and maintaining compatibility with other init systems. There was an option to do so in the init system GR, and it did not win. So while the GR allowed for project consensus to shift over time, I don't think acting as if option F "focus on systemd" won within the same release cycle is really on * We've talked about the burden already; there are people willing and able to help with this, and that offer remains good, be that by providing patches, MRs, help with bug reports on non-systemd systems, NMUs, or some other mechanism that Michael would prefer * I think the difficulty of elogind support is overstated - in the case of network-manager, there are a number of people who are running it thus without issue Regards, Matthew
