Bug#1101532: systemd: unable to migrate to Testing because of removed packages

[Josh Triplett]

On Wed, 2 Apr 2025 20:01:19 +0000 stefanor at debian.org wrote:
> Hi Josh (2025.04.02_19:27:34_+0000)
> >I think it's important to distinguish between "communication problem"
> >and "obstruction". "obstruction" is a problem that goes to DAM;
> >"communication problem" can potentially look like that, but once it's
> >resolved as *not* being that, it should ideally be rapidly de-escalated.
> 
> Absolutely. In abstract, at least.
> 
> We have been watching where this goes and trying to see the changes we 
> decided on land. There has been a lot of communication. But I'm afraid 
> things have not de-escalated, because this wasn't just a simple lack of 
> communication.
> 
> I think Luca set himself in a strongly entrenched position, and was 
> unwilling to give any ground. I'm afraid this is a pattern I've seen 
> before.

Not disagreeing with that, and I am not in any way endorsing the
communication style or patterns; far from it. I can, however, sympathize
with how people can *end up* in entrenched positions.

> >One could alternatively observe that an MR could have been provided
> >earlier in the process, and the iteration could have started then. I
> >don't think it's *entirely* on the maintainer to have started earlier in
> >the process.
> 
> The Debian Constitution defines how the CT is to take decisions. MRs 
> are not part of the process.

I'm not suggesting that it is. But at the same time, it's often healthy
if there are concrete proposed changes by the time the TC is
deliberating, and *again*, it's not on the maintainer to implement
things they disagree with.

By way of example, it should have been detected much earlier in the
process that the right way to "turn off mDNS in the default
installation" is to install a configuration file, not to change the
compile-time default.

> Yes, it could be helpful to hash out 
> detailed implementation examples of all the solutions on the table, 
> before the TC votes. But in practice, I don't see that happening very 
> often. Changes that come to the CT are often big enough that they can't 
> be completely fleshed-out pre-vote, we're making higher level decisions.

Sure, but in this case, the changes *weren't* particularly large. Most
of the approaches to addressing the mDNS issue could be implemented in a
few lines.

> >> While the TC was debating these issues, the Debian systemd package added a
> >> policy to not carry patches that were not upstream. That probably tied the
> >> maintainers hands quite a bit.
> >
> >That has been the policy of the package for a long time, and the only
> >new thing was *documenting* it. It's not a new policy.
> 
> I assumed as much too. But again, I don't think package maintainers can 
> declare that something is out of bounds for a CT decision. 

Sure, the TC *can* make any arbitrary decision, including overriding
package maintenance policies. That doesn't mean they *should*, if those
policies aren't *directly* in the way of solving the problem.

On balance, I would venture that TC should make the narrowest ruling
that directs the problem to be solved and un-sticks a dispute, rather
than over-prescribing implementation details. (The TC ruling partially
did that and partially didn't.)

In any case, the point of my comment was that you implied the policy was
*new*, and I was observing that it wasn't new, so it wasn't a reaction
to this incident.

> >> 1. Implement the changes myself before the NMU's deferral delay.
> >> 2. Reply to the NMUer (and TC) saying: "I'll handle this by $date".
> >>    Only then cancel the NMU. And, of course, follow through with the
> >>    implementation.
> >
> > The impression I have was that this was option 2, and the thing missing
> > was the "by $date".
>
> I had private conversations with Luca, to try to see where he was coming 
> from. And I did not get the impression that he would commit to implement 
> changes that he didn't agree with.

Having not been privy to those private conversations, I'm not in a
position to comment on or judge that. I was going solely off of
observations of the public communication.

> I think he was hoping to find different solutions to the problems that
> would satisfy the TC. And there is scope for doing something like
> that, but it requires communication and discussion. Most importantly
> it requires listening to the other side, and taking their position
> seriously.

Honestly, I think that there was an utter failure of that on *two*
sides, not just *one*. Obviously, engaging would have helped lead to
better solutions. At the same time, I don't particularly have an
impression that the underlying motivations or values behind systemd's
policies were particularly taken seriously or empathized with; none of
the alternatives that are *now* coming up were generated previously
despite them being reasonably obvious.

> >I certainly don't think the TC or anyone else expected "remove the
> >packages" as the solution, but at the same time, I can also *understand*
> >how someone would land on that: "well, the response to attempting to
> >iterate on an implementation of the ruling is to treat it as defying the
> >ruling and escalate, so here's something that should definitely meet the
> >requirement so that things stop escalating".
>
> Yes, but that isn't a serious position. It's obvious that the packages 
> wouldn't be able to migrate to testing in that hobbled state, and that 
> the TC would not be satisified.

That is not at all obvious. It's certainly not an *ideal* solution, but
I don't have the impression it was being presented as one; I have the
impression it was presented as "do the simplest thing that meets the
TC's ruling so that there is no longer external pressure and ongoing
escalation".

And to use the /lib64 issue as an example, it would not be the first or
hundredth time in Debian that a problem gets solved by *first* adding a
`Conflicts:` and *later* figuring out a better solution and removing or
versioning the `Conflicts:`. That doesn't mean the `Conflicts:` are the
ideal solution, but sometimes you solve an RC bug by introducing a
`Severity: normal` bug and then later fixing the `Severity: normal` bug.

The ruling was "base-files should own all top-level filesystem aliases,
and packages that conflict with this must be patched in Debian to avoid
creating any aliases that conflict with base-files". systemd was patched
(and is continuing to be patched) to add `Conflicts` such that no
combination of packages that can be installed together will result in
the creation of any aliases that conflict with base-files. This
obviously introduces a new problem, that people may wish to use packages
together that now conflict, and may wish to use systemd-nspawn on arm64.

To be clear, I'm not naive here, and I expect that the implemented
solution had some basis in spite-driven development (SDD). I don't
particularly like the solution either; I use systemd-nspawn sometimes,
and would like to be able to rely on it on arm64. I hope that a better
solution arises. But that future solution can be iterated upon at
leisure, and was not something the TC ruled on.