Control: tags -1 moreinfo Hi Andreas (and other interested parties)
On Sat, 25 Jul 2015 13:08:32 +0200 Andreas Beckmann <a...@debian.org> wrote: > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > during a test with piuparts I noticed your package fails to remove. Can you please elaborate on your test (and what you think is reasonable to expect)? I may be wrong, but it seems you are preseeding answers to the debconf questions of pdns/dbconfig-common which may be a little weird in this case. You are removing the mysql-server and still request the package in question to purge the database first. Also I believe you are using the non-interactive frontend (is that correct?) Anyways, we may have a difficult choice to make (please help). First the background ideas. 1) The idea of having the possibility of having the clients as a recommend instead of a depends is that the system admin may opt-out of dbconfig-common assistance and configure the package manually that depends on dbconfig-common to do the db configuration. Most packages don't need the client to operate, only dbconfig-common needs it for configuration (which may be skipped). But dbconfig-common shouldn't depend on all the different db clients that it supports, while that also pollutes the system. Unfortunately, once dbconfig-common is running, there is no way to install the required client on demand until bug 421055 [1] is fixed. 2) The idea of failing during removal/purge stems from the idea that you want the package that is removed to clean up e.g. any credentials still laying around and possibly also the database. If I would opt-in for this, I would want to be notified rather noisily when this fails; in dbconfig-common you currently get an error with accompanying question if you want to abort/retry/retry with questions/ignore. Also, if the package is configured with dbconfig-common, I would expect it to be possible to clean up with dbconfig-common. Remember that the database may not be on the same system as where the client should be running. Now, what you are requesting here is that we either break the first idea or the second and I am not sure which one to choose. An idea however, for installations (as in, during install) with the non-interactive frontend, dbconfig-common already defaults to ignore. I am not sure if it is a good work around for this case, but would it actually be acceptable for you and do you believe it solves your reported problem? Paul [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421055
signature.asc
Description: OpenPGP digital signature
