Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Sun, Dec 27, 2020 at 10:05:37AM -0500, Sam Hartman wrote:
> >>>>> "Wouter" == Wouter Verhelst <firstname.lastname@example.org> writes:
> Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
> >> 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.
> Wouter> Personally, I think both of these options are terrible and
> Wouter> will fail to fix the situation long term.
> You then go on to talk about init scripts.
If that is what you took away from my email, then I should probably have
written it differently so my message was clearer. Apologies about that.
I don't think that either elogind or init scripts are really the heart
of the matter here. What matters is that there are two opposing visions
about what Debian should become, that both these visions have valid
technical needs, and that deciding that we have to go with one or the
other isn't going to solve the issue; people will continue talking about
wanting to do what they want to do.
Debian isn't Fedora. Fedora has a "steering committee" (FESCo) which
decides on what to use in the future, and their word is final. If you
want to do something in Fedora that FESCo decided against, you're out of
luck. It means far less arguments, and there is something to be said for
doing things that way, but historically, it's not what Debian has done.
In my opinion, this diversity is one of our strengths, and making a
decision either way like you suggest is not going to help anyone.
> I found that really frustrating because I was talking about elogind,
> not init scripts.
Honestly, I don't think you can realistically do that. The no-systemd
people don't actually care about elogind; they only want it because
there is software out there which requires an interface provided by
logind, and elogind provides the same interface outside of systemd, and
so you can theoretically run NetworkManager without systemd if you
install elogind, or something along those lines. So while making a
decision about elogind may solve the bug at hand, it doesn't really
address the bigger issue, and then if we do that we'll be back here in
six months. Perhaps that's all we can do, but I do think it's worth
pointing out that it will happen.
As far as "developing alternatives" go: as I understand it, the end goal
for no-systemd people is not "something that doesn't exist yet".
Instead, the end goal is "we want to use what we have been using a long
time and what we thinks works just fine and we don't want this
newfangled mess, thank you very much". By allowing them to use elogind
but not init scripts, and then telling them that they have to write
something not-initscripts and also not-systemd if they want to move
forward within Debian, you're not saying something they want to hear.
That is, unless your end goal is to tell them to go do their thing
somewhere outside of Debian (which would be a valid position if it
happens to be how you feel about the issue, but it's not one I share).
In other words, I think the two are entangled, and I don't think you can
decide to only handle one of the two if you want to solve the issue at
(however, it is certainly possible to provide different solutions for
the two; e.g., you can say that the maintainer should add elogind as an
alternative dependency, but that init scripts should be elsewhere, in a
package maintained by no-systemd people)
> My reasoning doesn't apply to init scripts, I never said it did, and I
> even gave entirely different reasoning about init scripts because I
> don't think the text you quoted is a good place to think about init
My reasoning is that init scripts are the end goal, and that elogind is
just a symptom of that end goal, and that therefore talking about
elogind in isolation serves no purpose.
> The GR, policy, and our discussions treat elogind and init scripts
> differently. I support the consensus of debian-policy, the and the
> majority of project members who voted in the GR in treating these issues
I don't think that's actually the case; but the vote was rather muddled
because some options on the ballot were written by people who didn't
actually support the position they were writing, so I can't say for
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a billboard