Re: merged /usr vs. symlink farms
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.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Reply to: