On Thu, 2015-07-30 at 08:57 +0200, David Kalnischkies wrote: > This example makes it quite obvious that your requirements are "keep > a minimal set of packages installed" while the requirement of libapt's > autoremove is "suggest only packages for removal which are completely > safe to remove". If "Suggest only packages for removal which are completely safe to remove" is supposed to be "list all which are completely safe to remove" then it doesn't manage to do that either. It fails given circular references, ie A depends on B depends on C depends on A. I guess it's designed for the "cleanup packages I played with for a short while on my laptop" use case. It does a sort of OK job at that. Only sort of, because when you move across flag days the dregs left libapt leaves behind can get it confused over which packages should removed so the upgrade can proceed. For my servers it's different. The inherent ambiguity of Debian dependency system that libapt tries hide becomes intolerable, meaning I don't want something to just choose between the possibilities on my behalf, I want to be informed so I can see the choices and have my decision explicitly recorded to I can repeat it. Leaving garbage packages (think "garbage" as in garbage collector) lying around on servers that are supposed to be clones left alone to maintain themselves for a while is equally unacceptable. In the end I gave up up on libapt and wrote my own dependency resolver. Fortunately libapt makes that relatively easy because it's API gives you access to all its internal working so you can re-use most of it.
Attachment:
signature.asc
Description: This is a digitally signed message part