Some more thoughts about this bug, acquired during Debconf in Heidelberg after discussions with multiple people (thanks).
1) apt-get could take Recommends into account when ordering the packages for removal. I will file a (wish-list) bug about that shortly. @ Andreas, I assume you run apt-get with --no-install-recommends (or similar via options)? I tested with installing recommends and then apt-get seems to just do the right thing. 2) I am going to update the documentation to describe that we recommend packages to Depends on their client, to avoid this problem. However, I still believe that Recommends should also be possible (the Debian dependency system just isn't very well suited for this use case, but see point 4). 3) For the use case of Andreas (Andreas, you still didn't answer my question in the previous e-mail), I think for non-interactive mode I am just going to ignore this problem during uninstall. So anybody that wants errors to be handled gracefully, don't purge packages in non-interactive mode... 4) For the long term I am thinking about restructuring the dbconfig-common package into multiple packages, e.g. dbconfig-mysql, dbconfig-pgsql, dbconfig-sqlite, where packages can depend on. Those dbconfig-* packages could then hard depend on the client. System administrators that don't want the help of dbconfig-common should then install dbconfig-no-thanks (or something like that) which must be an alternative in the depends list of packages that require dbconfig-common. This way I also solve the issue that dbconfig-common can't determine at config time if the client will be available at postinst time. The cost is multiple packages, but I believe it outweighs the problems it solves. Thanks to AJ for the idea. Paul
signature.asc
Description: OpenPGP digital signature
