I have a package that installs a database and user in the postinst via
dbconfig-common, with dbc_dbuser=vdmt and dbc_dbname=vdmt.  The database
is created successfully, the mysql user is created succesfully, and the
user shows up in mysql's 'user' table:

| localhost | vdmt             | 55ae788633352193 | N           | N
      | N           | N           | N           | N         | N
  | N             | N            | N         | N          | N
    | N          | N          | N            | N          | N
          | N                | N            | N               | N
         | N                | N              | N                   | N
                | N                |          |            |
 |              |             0 |           0 |               0 |
             0 |


Upon purging the package, if I tell it (via debconf) to remove the
database and user, I see:

dbconfig-common: dumping mysql database vdmt to
/var/tmp/vdmt-mysql.vdmt.2006-11-27-02.29.mysql.O14213.
dbconfig-common: dropping mysql database vdmt.
dropping database vdmt: success.
verifying database vdmt was dropped: success.
dbconfig-common: revoking privileges for user vdmt on vdmt.
revoking access to database vdmt from vdmt@localhost: success.

The database is gone, the related entry in mysql's 'db' table is gone,
but the entry in mysql's 'user' table is still there.  It would be nice
if this user was completely removed from mysql.

hey dilinger,
<snip>

my rationale here is that the database account may be used for other
purposes beyond the scope of the package, so revoking access seems a
more prudent thing to do given that it doesn't really do any harm
to have a privilege-less mysql account in the database, but it could
significantly do harm to remove the user entirely.  the line of thought
isn't too far off from the approach to handling unix/system accounts.

of course, i'd be willing to accept some form of patch that made this a
global "delete mysql users on purge" type configuration option.


	sean