On 1/3/20 7:31 PM, Russ Allbery wrote: > The guidance of option B is that we are committing to reviewing and > working collaboratively with anyone who wants to support alternate init > systems, but that implementation strategy is subject to technical review.
It reads: "However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features." Exploring alternatives is precisely what I'm doing. The same way I've felt harassed when I did the original porting of OpenRC to 1/ Debian, then 2/ kFreeBSD, then 3/ Hurd, I do feel like everyone is rushing into me for no reasons. Could you please stop doing that, both you and Sam, and instead, help me with deciding how both implementation can cohexist? > I think Sam is providing that technical review by pointing out the > drawbacks of using multiple competing implementations. That's a valid > point of technical discussion; you may disagree with him, but I think that > discussion is explicitly enabled by the GR result. Yes, there's drawbacks in general. However, you *cannot* just say, we're going to use the systemd implementation "just because it's the refrence", without even giving me some space to at least *TRY* the alternative, to see if it's valuable or not. At the moment, I only saw FUD in this thread, nobody was able to point at missing feature or wrong implementation. This is very annoying and frustrating. I very much don't agree that the GR result tells that we should use absolutely all implementation from systemd as the default, no mater what, and that there's no room for alternative implementations. This was proposal "Choice 1: F: Focus on systemd", and that's not the winning option. The project has chosen "Systemd but we support exploring alternatives", so please let me do just that, and give a chance to the alternative to maybe win. Otherwise, I just give up as well, and do something else (believe me, I do have a lot of things in my todo list to improve Debian...:P ). > That's a lot of work, and with my Policy hat on, I'm not committing to > doing that work because I see the GR as asking me to spend my limited > resources on other things, and also asking that we move a little bit more > decisively in the direction of adopting systemd facilities than that > (albeit not as decisively as option F). Adopting systemd facilities is *NOT* the same as adopting systemd implementation blindly, no mater what it is and does. That's not what "Choice 2: B: Systemd but we support exploring alternatives" is about. > Therefore, I think it's a reasonable question to ask whether we want, as a > project, to commit to supporting the least common denominator between > several competing implementations of these facilities, or instead ask that > people arrange to run the systemd implementation so that we have the same > features everywhere. > > Support for kFreeBSD and Hurd is obviously a valid argument in favor of > some level of support for non-systemd implementations. As I wrote earlier, there's an easy path out: drop the systemd implementation entirely, and standardize on open{tmpfiles,sysusers} implementation. But maybe we should first *try* open{tmpfiles,sysusers} to see if it has any value. At the present moment, I just don't know yet if it can be a good or a bad replacement. Again, *PLEASE*, let me at least try to have a working package, that is somehow useful. We're not there yet at all, there's not even an init script, or a way to replace systemd-X binaries. Cheers, Thomas Goirand (zigo)