Comment 11 for bug 1579708

On Tue, Jun 02, 2020 at 01:28:58PM -0000, Giles Birch wrote:
> "This is expected behaviour since policy is that users' modifications of
> conffiles (for example, files in /etc/mysql/) should be preserved."
> makes absolutely no sense when the problem is that /etc/mysql has been
> deleted. In the case where there is no config to overwrite, the script
> should reinstall default values, and there is no danger in doing so.

There is no such guarantee. A user might have customized the mysql
service to look somewhere else for configuration, for example, but
some clients may still look in /etc/mysql, find nothing, and continue as
normal. Re-adding /etc/mysql with a different configuration would break
that arrangement, and a user affected like that could quite rightly
complain that special casing MySQL packaging against established
packaging policy was surprising and wrong.

There are other (not-MySQL) cases where removing a file from /etc does
correctly adjust a service rather than completely break it (for example
as a mechanism to switch to upstream defaults rather than packaging
defaults).

We cannot both deal with this special case and also behave correctly for
other users who expect the general rules to be followed.

> What the package maintainers seem to be saying is "hey, too bad your
> attempts to fix bad config went wrong and you decided to start again, we
> won't help you at all."

I have no objection to heuristic detection and pointing users to a
solution, if you want implement and contribute that. For example, this
could detect the situation and print a message along the lines of "if
you deleted /etc/mysql in the hope of restoring defaults, actually you
need to purge the packages and reinstall them".