Hi David, On Fri, Oct 18, 2024 at 08:00:47PM +0200, David Kalnischkies wrote: > So, technically this isn't autoremove being clever, it is "just" some > code hidden deep in the internal solving that makes autoremove look > good later on – and one of the reasons why alternative solvers like > aspcud, solver3 or the one in aptitude have a hard time catching up. > Resolving Depends is (fsvo) easy, the fun starts with Recommends and > heuristics like this one. > > (So, why not autoremove, you ask? It would need to invent a way for the > user to declare that they want to keep the transitional package anyhow > for example)
That's significantly more voodoo than I was expecting but it seems reasonable :) The only question I have is can we document this better? Looking through the pertinent manuals (policy, devref, newmaint, debmake) I dont find any mention of these mechanisms. Am I missing some obvious place or keywords? Devref only mentions deborphan but that's an entirely seperate thing as I understand it. > Bonus tip: > If you 'cheat' and test your upgrades with `dpkg -i` this and many other > things wont happen, so don't cheat, test them properly! If you don't > feel like setting up a repository you can skip that with e.g. > apt full-upgrade --with-source ./path/to/foo.changes Now I feel smart for always upgrade-testing with my full blown local apt repo despite not having had any idea what's going on behind the scenes :D Thanks for taking the time to explain this David, --with-source is also new to me and was already super useful for libcurlfs upgrade testing :) --Daniel
signature.asc
Description: PGP signature
