On Sat, 2021-08-21 at 10:26 +0200, Wouter Verhelst wrote: > On Fri, Aug 20, 2021 at 11:21:55AM +0100, Luca Boccassi wrote: > > On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote: > > > On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote: > > > > > > > > I think no one likes that idea, but it's the only solution that > > > > doesn't > > > > immediately fail because it requires a dpkg update that hasn't > > > > shipped with > > > > the current stable release, breaks local packages (kernel > > > > modules, firmware, > > > > site-wide systemd configuration), or both. > > > > > > This could be solved if we could somehow require dpkg to be > > > updated > > > before any other packages during the the next update, no? > > > > > > Breaking this constraint means that we can't make "apt-get > > > dist-update" work seemlessly --- but what if we were to change > > > the > > > documented procedure for doing a major update? > > > > > > That's not ideal, granted, but how does that compare against the > > > other > > > alternatives? > > > > > > - Ted > > > > > > P.S. I had a vague memory that there was some update in the long > > > distant past where we did require a manual upgrade of dpkg > > > first. Or > > > is my memory playing tricks on me? I do know that a manual > > > update of > > > dpkg is the first step in a crossgrade.... > > > > An update to dpkg is not _required_. It might be very strongly > > _desired_ which is a perfectly legitimate stance to take, but it is > > not > > technically required, otherwise we couldn't have been shipping with > > merged-usr as default in new installations of Buster and Bullseye > > for > > 2+ years, we could not have been installing usrmerge in older > > installations for 2+ years, and Ubuntu would not exist anymore > > since > > legacy split-usr is discontinued and even older installations are > > being > > forcibly converted. So continuing to live with this minor ~20 years > > old > > dpkg bug as we've been doing for years is a valid option - one that > > some might very, very strongly dislike and argue against which is > > again > > perfectly legitimate, but it is de-facto an option nonetheless, > > because > > it's the actual status quo for 2+ years. > > It bothers me that you believe "we've been doing this for a while and > it > didn't cause any problems, so let's just continue doing things that > way > even if the people who actually wrote the damn code say that path is > littered with minefields and they're scared of what could happen when > we > finish the tranition this way" is a valid strategy. It goes against > everything I was taught to do to write reliable software. Many people are bothered by many things - such is life. For example, I am very bothered that it appears impossible to do any kind of project- wide innovation in Debian, and that we have been delegating that to other distros since forever, and seem condemned to, at best, frantically play catch-up, and at worst be dragged, kicking and screaming, into what has been normal everywhere else for a decade, by upstreams tired and frustrated of having to maintain legacy code paths for the sole and exclusive benefit of this project. But I digress. The main point is that of course the insights of experts are extremely important, incredibly valuable and worth careful consideration, especially when making decisions about an unknown future and events yet to unfold. But in this case these are predictions about the past, a past that already exists and is lived experience for many users here, and for all users in Ubuntu. So there need to be _very_ convincing explanations on why these predictions do not seem to match reality at all, and so far these explanations have failed to materialize, I'm afraid. We have been told everything is broken and the sky is about to fall any minute now, and yet we have not been inundated with new bugs since Buster made merged-usr the default, we have not been inundated with new bugs by users upgrading from Buster to Bullseye or installing usrmerge (despite the yet unsubstantiated claim in this thread that apt dist-upgrade would stop working and require abandoning as a way to upgrade the distro), and Canonical is not drowning in bug reports for making usrmerge the mandated reality of 100% of its user base. The usrmerge Launchpad has 2 (two) bugs [1]. The usrmerge Debian page has 4 (four) bugs, two of which are feature requests [2]. This is hardly the stuff of nightmares. If one's expert viewpoints and predictions do not match reality, they are not entitled to gloss over it because they are the recognized and widely appreciated foremost expert in the field. The reality of this industry is that reliable software is an oxymoron: the only bug-free software is the one that doesn't exist. So the question becomes, what is the measurable impact and magnitude of known bugs and what is the likelihood and projected appearance rate of unknown bugs given measured history. The objective answer for this case is that the known, measured, unsolved and user-visible impact is having to sometimes type 'dpkg -S' again, adding/removing a 4 characters suffix. I can only dream that all the software projects I work on could have something of this magnitude as the actual worst-severity reported bug, as my stress and burnout levels would drastically plummet. -- Kind regards, Luca Boccassi [1] https://bugs.launchpad.net/ubuntu/+source/usrmerge [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=usrmerge
Attachment:
signature.asc
Description: This is a digitally signed message part