[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#994388: dpkg currently warning about merged-usr systems

On Thu, 2022-03-24 at 13:24 -0700, Russ Allbery wrote:
> Josh Triplett <josh@joshtriplett.org> writes:
> > On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery <rra@debian.org>
> > wrote:
> > > That said, I personally am disappointed that the folks who have
> > > been
> > > pushing merged-/usr forward are willing to leave dpkg in a known-
> > > buggy
> > > state without attempting to patch it to fix the remaining
> > > issues.  I
> > > realize that there are various obstacles in successfully doing
> > > that,
> > > not all of which are technical,
> > I don't think "willing to" is a fair characterization here.
> It's possible that you haven't seen the discussions that I've been
> in, but
> whenever I point out that this hasn't been fixed and that we should
> fix
> it, I am told, often quite emphatically, that Ubuntu has never seen
> any
> problems and therefore this problem is not important and no one needs
> to
> fix it.  It's hard for me not to characterize this as "willing to"
> leave
> dpkg in a state that I'd characterize as buggy.
> I certainly agree that there are also other challenges in fixing
> dpkg.
> However, it would be nice if we could at least agree that it's
> necessary
> to fix dpkg, rather than arguing that it's fine to leave it in its
> current
> state.  (In fact, I suspect this belief that the current state is
> fine and
> reasonable to leave things in permanently is part of what's making it
> harder to discuss how to best fix dpkg in a way that is sustainable
> and
> supportable going forward.)

You are inverting cause and effect here. We are saying that's it's fine
to write off those small issues because it's believed to be impossible
to get them fixed, and it's thus a very real and reasonable way
forward, not the other way around. It became impossible to get dpkg
fixed long before any of that, and before this latest public
escalation. If it was possible to do it, it would have already
happened, and we wouldn't be discussing it at all, it would have just
been done. But it's obviously not, as recent events show, so either we
decide to give individual maintainers veto rights over the TC when they
personally don't like a committee's decision (but I want to have a veto
too though, or are only "special" maintainers going to have it?), or we
find a way to move forward with the decision.

You might not like to hear it, but it's perfectly legitimate to take a
pragmatic approach and look at a more popular distro, with the same
tools and better infrastructure, more users, more backing, more
deployments etc and see that after all, they are doing just fine, the
sky hasn't fallen, so severity can't really be that bad. The only
perfect and bug-free software is the one that's never been written.
dpkg has literally hundreds of bugs open against it, some decades old,
and yet nobody's screaming bloody murder at them, but somehow this one
spells the end of the world. And in the end I suspect you know
perfectly well _why_ this one is controversial and the hundreds of
others are not.

In the end, at the very least this is a _workable_ proposal. It might
not be ideal, but we know it can work. What's your counter-proposal?
Sitting back and just saying "someone better get a fix into dpkg",
without neither doing it nor explaining _how_ that could ever be
possible is not a workable proposal, it's just doing nothing while
letting the clock run.

Kind regards,
Luca Boccassi

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: