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

Re: merged /usr vs. symlink farms



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.

-- 
Kind regards,
Luca Boccassi

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


Reply to: