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

[Olaf van der Spek]

On Mon, Jun 11, 2012 at 5:48 PM, Nicholas Bamber <nicholas at periapt.co.uk> wrote:
>> 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.

I'd class NEWS as documentation.

>> 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.

Preferably not. Of course it's a tradeoff. What's the risk if NEWS
isn't read vs the usefulness of the change.

>> 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.

If they don't know already, it's unnatural isn't it? Otherwise it'd be
natural / common sense.

> 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.

Whether it only provides to new installs is hardly relevant I think.
Databases from new installs are important too.

>>
>> 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

I'm not. But I'm trying to argue that one should not depend on that.

> 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.

Probably isn't good enough when it's about important user data.
When there's an emergency and the user is in a hurry, the warning
might get lost.

> 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.

We don't :p

> 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.

Hmm. Not sure whether that's relevant.

You could maybe enable it during testing and then disable it again
before next freeze to avoid it being an issue in stable.

>>
>> 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.

Are we talking about two different kinds of exceptions?
When I'm talking about an exception, I mean telling piuparts to ignore
/var/lib/mysql
Not to skip piuparts altogether.
Or would ignoring /var/lib/mysql not be sufficient to catch bugs and
do piuparts testing?

>
>>
>>
>>> 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

But mysql-source-5.5 is only used for building stuff I assume, not for running.

> 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.

I thought the test suite was the biggest offender. But yeah, look at
what stuff is big but not always needed.

Olaf