Re: opentmpfiles & opensysusers, and its use in the Debian policy
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)
Reply to: