Hello. Theodore Ts'o - 14.07.19, 22:07: > So requiring support of non-systemd ecosystems is in general, going to > require extra testing. In the case of cron/systemd.timers, this > means testing and/or careful code inspection to make sure the > following cases work: > > * systemd && cron > * systemd && !cron > * !systemd && cron > > Support of non-systemd ecosystems is not going to be free, and some > cases, it is not going to be fun, something which many have asserted > should be something we should be striving for. The challenge is how > do we develop the consensus to decide whether or not we force > developers to pay this cost.
I believe forcing someone who does volunteer work by maintaining packages for Debian is not going to work out. Or even more so: I do not see how Debian project could force developers. The only effective way to force anything would be to threaten with loosing membership status or privileged. But I would not go that route as I see it as destructive one. > And if we don't, is it better to just let this rot where we allow > developers to violate current policy with a wink and a nudge until > it's clear that we do have consensus? Or do we force them to do the > work? Or do we somehow go through the pain and effort to try to > determine what that consensus actually is? I do not have a solution for the divide behind all of this. But I do have some hints that may be beneficial or constructive to someone: There is a group of Debian developers in the Debian Init Diversity team working on exactly that: diversity regarding init systems. This is a group consisting on both Debian and Devuan developers who decided that working together is going to benefit both Debian and Devuan. Some people of that group did a *ton* of work to improve sysvinit, insserv, startpar, runit and I believe also openrc packages. When I look at the bug tracker I believe sysvinit in Buster is in a better state than it was since a long, long time. It even has a new upstream maintainer who actively dug through Debian bug reports with the aim to fix as much upstream bugs as possible. Also another developer worked on elogind package. I running Debian Sid with Plasma desktop on Sysvinit since more than a month already. It needed some minor tweaks as for example Pulseaudio was not started automatically and Evolution which I use for work needs some services that are nowadays started by user systemd service files. I am currently using some quite half baked user services frontend for runit for starting these I worked on some time ago. So I believe there is some talent to draw from when it comes to supporting alternative init systems within Debian packages. Both within Debian and Devuan communities. So far the Debian init diversity team runs their publicly accessible mailing list on infrastructure outside Debian, also to stay out of the heat of all the discussions regarding systemd and focus on getting actually work done. As for the fio package I maintain: I did a sysvinit script myself for it and I am gladly willing to accept patches to support other init systems. During that work I was even able to improve upon the upstream systemd service file considerably as I learned about an option to daemonize fio I was not aware of. Testing sysvinit stuff can be done on either Debian or Devuan inside a VM. Actually for me it is the other way around: To actually test the systemd service file for the fio service I need to use another system meanwhile, as my main laptop runs on sysvinit and elogind since more than a month and I have no intentions to change it back at the moment. Instead I plan to switch my other laptop as well, which should be as easy as: apt install elogind libpam-elogind-compat sysvinit In addition to that if you have some cron job or sysvinit script which requires some testing I am happy to help out as I manage to allocate time for that. I am not sure whether that libpam-elogind-compat package from experimental is still needed. Also it can easily be switched back to Systemd as well as well. That mentioned I believe there is no use in forcing anyone to do anything within the Debian project except what is necessary to maintain the boundaries of a code of conduct which helps everyone who uses Debian or contributes to it welcome. Again, I do not have a quick or easy solution. And I may be the only Debian package maintainer who switched his main system to sysvinit, but… it may still be interesting to read about this different perspective here. I did not share my reasons for switching to Sysvinit. Simply because I am just not interested in triggering yet another discussion for or against Systemd here. Thanks, -- Martin