[Dbconfig-common-devel] DB problems with removing/purging

[Cameron Dale]

Hi,

I've noticed some errors that can occur when a package that uses
dbconfig-common is removed or purged, and then reinstalled. I found
the following 2 scenarios:

When a package using dbconfig-common is removed, and the option to
remove the database is selected, a reinstall of the package will
result in a silently (i.e. no error messages during install are
printed) non-working package. The database is not created at all on
reinstall for some reason.

When a package is purged, and the option to remove the database is
either chosen or not, a reinstall of the package will result in a
silently non-working package. Since the old database user still
exists, with the old password, the newly created password for the same
user will not work.

I was going to report these as bugs, (possibly even as serious ones,
though removal/reinstall is not mentioned in the policy, it is
mentioned as one of the minimum tests to do in the developer's
reference) but I see that there are already 2 similar reports:

#400566 dbconfig-common: should remove mysql user

The response to this is: "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"

#439078 dbconfig-common: passwort of db user is not updated

The reporter suggests: "If [...] the user does not provide a password
for the user bar, dbconfig-common should update the password of the
mysql user with the newly autogenerated password iff bar has only
access rights for db foo. If the administrator has granted the bar
user additional access right for other dbs, the password shall not be
updated as this would potentially break existing setups."

It seems to me that dbconfig-common could use some better checks and
procedures for handling removal/purging of packages. Since there
doesn't seem to be an obvious solution, I thought I'd start a
discussion on what those could be, instead of just filing some bugs.

My initial suggestion is that, since both scenarios resulted in no
errors but a non-functional package due to the DB not being
accessible, I think a basic check of DB connectivity with the DB user
should be performed before the installation terminates. If this check
fails, there could be other options to present to the user, such as
trying again with a different user name or resetting the password.
What do you think?

Thanks,
Cameron