[debian-mysql] Groping for a roadmap in the dark

[Nicholas Bamber]

On 11/06/12 15:42, Olaf van der Spek wrote:
> On Fri, Jun 8, 2012 at 1:55 PM, Nicholas Bamber <nicholas at periapt.co.uk> wrote:
>>> Piuparts is an awesome assessment of where we stand w.r.t. policy. Its
>>> true,
>>> we are not automatically purging data if the question about whether or not
>>> to remove /var/lib/mysql/* is left to defaults.
>>>
>>> I'd entertain making mysql-server-5.5/postrm_remove_databases default to
>>> true
>>> rather than false, as long as it is noted in NEWS, and the question is
>>> given
>>> a high priority. As I understand it, this would solve the issue entirely.
>>
>>
>> It seems we are in agreement. Basically I think we need to do everything we
>> can to alert the user to this change. This will include having the change in
>> either experimental or unstable for most of wheezy+1.
>>
>> Olaf however will doubtless disagree. I would like to make sure he has an
>> opportunity to make his case. There is a while before I get  to piuparts on
>> the roadmap.
> 
> Certainly. Do we know what Postgres does yet? Do we know if a piuparts
> exception is possible?

Postgres deletes the data. I have seen a piuparts exception for not
deleting a home directory of a system user (as per Debian policy).

> 
> Users don't (like to) read docs.
Docs are irrelevant here. We can't ship the upstream docs for copyright
reasons and any patch to that would get lost even if we could.

> They might not read NEWS, for whatever reason. 
I plead guilty to generally not reading NEWS though I intend to correct
that.

> Users shouldn't be bothered.
Hmm. What I understand by this is that no change to Debian software
should ever be made that might require the uses to read the NEWS that
comes with the package on upgrade.

> AFAIK purge doesn't delete data, it deletes conf. Users expect the
> same, otherwise you wouldn't have to bother with NEWS and questions.
No I don't agree that we are proposing to do something unnatural. We are
proposing to *correct* and *standardize* the behaviour in a way that the
users need to know about.

On the data/conf issue Debian Policy is essentially silent so the
statement is "purge doesn't delete data, it deletes conf" is a possible
interpretation of the policy but not a necessary one.

There is a bug report covering this exact issue,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535577. My reading of
the consensus in that is that *if* we delete the data, we must
explicitly ask the user via debconf. That is precisely what we are
proposing to do. Furthermore this only applies to new installs -
probably from 5.6 except for the experimental distribution.

> 
> It's like first setting a trap and then putting up a warning sign.
Umm no. First of all you are ignoring what can be done to warn the user
from within debconf - both during the initial install and before the
actual purge. Sure that can be suppressed as well - presumably for an
automated install (or even a piuparts test!), but in that case we cannot
be held responsible, since the user is claiming to know better and
should be testing his automated install.  And then we should probably
catch him on the purge anyway.

Secondly responsible users should keep backups of critical data. Sure if
something in the installation deletes data unexpectedly that is a
serious bug. But the question is just how do we ensure that the user
expects it.

Thirdly we are proposing to do this at the earliest possible moment in
the next release cycle and engage the users as much as possible in a way
that we did not do this time.

> 
> Why are we trying so hard to avoid a piuparts exception?
Okay somewhere between a quarter and a third of the bug reports, I would
rather not touch without being able to do piuparts testing. I am not
saying that piuparts would constitute adequate testing, but it really
should be necessary.


> 
> 
>> So I throw the question back to you. How would you respond to #511438?
> 
> How big is the test and other optional stuff? If it's significant it
> seems reasonable to split it.

Well the biggest package is mysql-source-5.5. Unfortunately not  a lot
can be done about that until we revisit how plugins are built - and that
is a low priority. The test stuff is a somewhat different question from
the server stuff, since the sort of user who complains about the size of
the server stack is never going to install mysql-testsuite anyway.

If I had to reduce the number of issues to improve the clarity of the
questions I would focus on #511438 rather than the test suite.

> 
>>>> 6.) Config modularity. The modern way would
>>>> be for mysql-config to store a skeleton /etc/mysql/my.cnf and something
>>>> to keep
>>>> /etc/mysql/conf.d alive. However we will have to keep just enough
>>>> in /etc/mysql/my.cnf not to break the existing 5.5. Each of the packages
>>>> would own its appropriate config fragment below /etc/mysql/conf.d .
> 
> Maybe we should remove documentation (and commented entries) from conf
> files. It's easy to include a link to the documentation and a clean
> conf file is easier to read.

I don't find that point very compelling. Comments can only enhance
readability so long as they are accurate and well-written. Can you give
an example of where they are not?

> 
> Greetings,
> 
> Olaf