Luca Boccassi <bluca@debian.org> writes: > 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. Well, quite -- we seem to have had predictions of the sky falling as a result of usrmerge and/or merged-/usr, but if it is falling it's doing it remarkably slowly. I've been paying attention to this for a while, what with being on the TC up until just before the unanimous decision (which I fully support). I'm as sure as one can be about the future that if in 20 years I am still around to type this into a supported Debian system: [ $(stat -Lc %i /bin) != $(stat -Lc %i /usr/bin) ] && cowsay Surprise! I will not see a talking cow[1]. I'm also pretty sure that the 2041 version of dpkg will either be completely relaxed about having /bin be a symlink, or we'll be using something else by then. That being the case, we might as well get on with it rather than trying to pretend that filling everyone's disks with shedloads of symlinks for a while in-between now and then is a useful thing to do. Cheers, Phil. [1] unless of course there's a reason to use some sort of bind-mount or other filesystem trickery that's invented in the interim to achieve the same result. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature