On Thu, 2022-03-24 at 13:24 -0700, Russ Allbery wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery <r...@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
signature.asc
Description: This is a digitally signed message part
