Bug#994388: dpkg currently warning about merged-usr systems
Russ Allbery dijo [Thu, Mar 24, 2022 at 04:50:44PM -0700]:
> > I think it's appropriate for people to wait on such work until there's
> > guidance from the TC ensuring that such a patch will be accepted.
> > Otherwise, anyone spending time writing it is spending substantial
> > effort that may well be wasted.
>
> I think this is a totally fair thing to be concerned about. Should such a
> patch exist -- with the obvious condition that I think it's quite
> reasonable to do several rounds of iteration on making that patch solid,
> ensuring there are tests, and so forth -- I think it's obvious that we
> should merge it given the previous TC decision. Of course, I'm not a TC
> member.
I have informally talked with some other TC members; I am a TC member,
but am writing just as an individual DD.
You have said the TC has ruled to make an NMU in the past. I doubt an
NMU would fly -- The dpkg maintainer does not want to engage with the
TC, and I believe odds are high we could end up playing NMU
ping-pong. That's not in the best interests of our users nor the
project.
However, TTBOMK, no patches have been proposed. However, even given
his attitude, I trust he would apply a correctly done patch addressing
the issue at hand.
> It's difficult, procedurally, for the TC to do anything about a
> theoretical patch that someone could write but hasn't written.
Precisely. We cannot mandate a patch to be written. We can (and I _do_
think we should) require the maintainer to remove this warning -- not
because it is false, but because torpedoing trust in the project is
not the right course of action.
> If a concrete patch exists, the TC can (and has in the past) authorize an
> NMU to apply it. Obviously, we should try to avoid reaching that level of
> social and process confrontation if we can avoid it, but this is clearly
> within the TC's constitutional power via a maintainer override, which puts
> the discussion on somewhat firmer ground. But design of that patch is
> *not* within the TC's constitutional mandate.
>
> It may be useful to look at how multiarch support in dpkg was handled.
> That was quite painful and I really hope we don't end up following that
> path exactly, but it provides a concrete example of how Debian's processes
> can reach a resolution.
>
> I personally am still hopeful that we could do much better than the
> multiarch outcome and find a patch that meets the architectural criteria
> of the dpkg maintainer, but I'm fairly certain that we're not going to
> make any progress towards that goal without having working code, or at
> least a very detailed architecture, to start discussing and analyzing.
Completely agree here.
Reply to: