On Wed, May 03, 2023 at 10:31:14AM +0200, Raphael Hertzog wrote: > On Tue, 02 May 2023, Helmut Grohne wrote: > > I think there is a caveat (whose severity I am unsure about): In order > > to rely on this (and on DEP 17), we will likely have versioned > > Pre-Depends on dpkg. Can we reasonably rule out the case where and old > > dpkg is running, unpacking a fixed dpkg, configuring the fixed dpkg and > > then unpacking an affected package still running the unfixed dpkg > > process? APT instructs dpkg to --unpack and to --configure in different calls, you can't mix and match those in the same call and apt never does the (combining) --install (not that it would really matter here). Also, dpkg is essential and as such has to work unpacked aka unpacking a fixed dpkg means that this fixed dpkg will (later) configure itself. Now, given dpkg is essential, it also means it gets the essential treatment from APT (by default) which means it will try to unpack it as soon as possible while trying to keep the time it remains unconfigured at a minimum. Give it a try, you usually see essential packages being interacted with first and in their own calls if you look close enough. That isn't an accident, the idea is that some random 'optional' package failing to install in some way should not leave you in a situation where essentials are in a state of limbo. If you increase the complexity of (pre-)requirements through APT will end up being forced to hand multiple packages in one go. Just pull up the last time you upgraded libc6: You will see a bunch of -dev packages and MultiArch siblings being unpacked alongside libc6 and libc-bin. You will only see those two being configured right after through. The dependencies will it is… so we might have to be a bit careful about the dependencies dpkg carries if such a route is taken. That said, there is always the 'stretch' horror story of APT installing all of KDE before touching dpkg because of the install-info transition… Although that was avoided before the release by removing from dpkg the Breaks leading us into this dark alley… (just to be sure: APT wasn't wrong, the dependencies weren't – but the idea to manually upgrade dpkg first to avoid some pitfalls was suggested which turned out to be wrong). Also, I wonder if we run into Pre-Depends loops and similar nasties given that the essential set is somewhat likely to pre-depend on things which use(d) to be in /lib which would in turn Pre-Depend on dpkg. (I haven't tried and memory is sketchy about those finer more complicated matters, but dpkg certainly can produce working orders for loops by inspecting which maintainer scripts exist or not, so upgrades involving those might or might not work. All bets are off which version of dpkg would be dealing with those through) > I don't know APT well enough to answer that question but from my point of > view it's perfectly acceptable to document in the release notes that you > need to upgrade dpkg first. Those never work in practice through. Nobody logs in on their buildd chroots and upgrades them "properly", we all just hope for the best. Even on systems we care more about people are regularity caught red handed by bothering support with questions whose answers are spelled out in detail in the release notes. Case in point: "Changed security archive layout" last time or "Non-free firmware moved to its own component in the archive" this time around… And those are easy to diagnose and fix. 'You "might" have some "random" files not present on disk. So your system might not even boot or spawns interdimensional portals. You better reinstall…' is not the type of thing you wanna here from support. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature