On Sat, Aug 21, 2021 at 12:47:51PM -0400, Theodore Ts'o wrote: > Personally, I *don't* have a problem about telling people to manually > update dpkg, apt, and/or apt-get before they do the next major stable > release (maybe it's because this is something I do as a matter of > course; it's not that much extra effort, and I'm a paranoid s.o.b., So, when did you last log into your build chroot to upgrade dpkg and apt first? And while at that, did you follow the release notes – from the future, as they have yet to be written for the release you are arguably upgrading to already? But okay, lets assume you actually do: apt and dpkg tend not to be statically linked, so they end up having dependencies. Some of them even surprising. In bullseye you e.g. have to upgrade cryptsetup first before apt can be upgraded (apt → libgcc-s1 → cryptsetup-initramfs → …). And that is just the first and most obvious chain. But it would never happen that you would e.g. need to upgrade all of the KDE desktop environment before upgrading dpkg, right? Well… in Debian squeeze that nearly happened, but we had to break that chain because it was actually forming a 500+ loop apt/lenny had trouble dealing with. Those chains are only investigated if they lead to major problems: I e.g. never looked at the C++ v5 (copy on write) transition which likely entangled apt with half of the universe in the general case. But okay, lets assume we form a team who actually looks into all these. It is easy, right? No. Dependencies and their version constrains (can) differ by architecture and mostly propagate by negative dependencies meaning the individual system state is hugely important. The result is that hardly any upgrade is the same even if we subsume it all under "upgrade to bullseye". And regardless of how hard we try, there will always be other packages which have to go before it is dpkgs turn, so at least all these have to make due with what was released previously anyhow. > and I know that's the most tested path given how Debian testing > works). Not really as you can see e.g. with libgcc-s1, as most upgrade problems aren't due to dpkg or apt in practice, but because the intermediate steps of a package making testing upgrades a smooth sail aren't visible for the stable updates. If you want a better tested path, I suggest stable updates by jumping from week to week via snapshot.d.o. You may want to skip weeks with actual bugs through. In the end, it is just simpler to assume that every release+1 package is installed by dpkg/release (and of course apt/release) than trying to reason if and how we can make it happen that dpkg is handled before some other package (without forming loops) or even can be sanely upgraded ahead of the upgrade entirely. Or are you perhaps volunteering? Don't get me wrong, as an apt dev I would love if we could do that. It is kinda annoying to work around issues you have fixed years ago, but aren't available in (soon) oldstable. We would need a more aggressive stable-updates strategy but in reality we tend to be held to even higher standards than all other packages because we are native key packages… (just look when we froze dpkg… apt at least has a tiny loophole for now by not being build-essential in a strict sense) Not that it really matters. It would just add more moving parts to the upgrade process – a process, if this entire thread is any indication, which is hardly understood by anyone in Debian and considered entirely optional by many. That alone makes me very sad on many levels. (I wrote this before reading Guillems replies which end on a similar note even though he comes from the opposite end – dpkg worried about the finer file-level details and apt about the general package-level picture meeting halfway as usual… kinda funny) Best regards David Kalnischkies P.S.: As someone will ask: Ubuntu splits the user base in two: Those who run their release upgrader which runs outside of the packaging system and largely can do whatever (including bring in a standalone apt/dpkg just dealing with an upgrade – they usually resign to much simpler things through) and those who don't like for example chroots and containers who effectively use whatever an upgrade path 'apt dist-upgrade' gives you. Which also explains why Ubuntu hasn't fully /usr-merged yet more or less waiting for Debian to figure that one out. Or, well, they spearhead even here now as it is apparently too much to ask for an upgrade path in Debian nowadays.
Attachment:
signature.asc
Description: PGP signature