tag 397089 + patch thanks Matt Brown wrote: > I think the solution to this bug is that dbconfig-common should check > the output to dbconfig-load-include to ensure that valid answers were > able to be extracted, and only load the answers into debconf if that is > true. If nothing could be read from the existing config, the user should > see a warning and dbconfig-common should proceed as if its a new > installation (ask the user if they want to use dbconfig-common, etc). > > I'll see if I can come up with a patch to implement this behaviour.
Ok, patch attached. This changes the behaviour of dbconfig common in three ways 1) If the dbconfig-load-include script fails to set dbc_dbtype it is assumed to have failed and none of its return values are used. 2) The user is always asked whether they want to use dbconfig-common to manage the database. Previously this only happened for new installs, migrations were assumed to want to use dbconfig-common. I see no justification for why the user shouldn't have a choice when upgrading. 3) dbconfig-load-include now runs before the state machine starts so that the user can make a decision on whether to use dbconfig-common based on whether or not the migration succeeded. I think this is a reasonable solution to the problem. I've only filed the bug as important as it breaks a subset of cases, but it would be nice to get this fix into etch if possible. Cheers -- Matt Brown Debian Developer [EMAIL PROTECTED] Mob +64 21 611 544 www.mattb.net.nz
signature.asc
Description: OpenPGP digital signature
