[debian-mysql] Discussion on handling 5.6 related matters

[Robie Basak]

Akhil,

Sorry for the slow response.

On Tue, Jun 17, 2014 at 11:21:25AM +0530, Akhil Mohan wrote:
> In continuation to the discussion at UDS, it might be easier if we draft
> the packaging design changes on mail to make sure everyone has the
> correct perspective. I am listing down the TODO list having impact on
> design of MySQL ecosystem in Debian and Ubuntu:
> 
>  1. Taking forward 5.6 as default in Debian and Ubuntu.

A work item for me is to examine the remaining delta for 5.5 in Ubuntu,
and apply it to 5.6 as necessary, making sure to feed everything back to
this list so that Debian can have the delta too.

>  2. Separation of data directory and common packaging scripts as part of
>     an independent package.

I propose that when we're ready with things to go in there, we have a
mysql-defaults source and binary package (probably "3.0 (native)"?).
This could contain any commonality across variants as we work on them.
Each variant that needs its functionality can depend on it.

Maybe even (optionally, as needed) a Pre-Depends so that variants can
use its scripts in preinst, etc? Or is this a bad idea?

>  3. Giving each binary incompatible MySQL variant its own data directory
>     at /var/lib/<fork>.

I think this could be a first step. I propose that:

1) We deprecate /var/lib/mysql completely.

2) mysql-defaults takes over "ownership" of legacy /var/lib/mysql
directories. I'm not sure if packages previously supplied shipped
/var/lib/mysql from dpkg's perspective, but if so then mysql-defaults
can Breaks/Replaces them.

3) mysql-defaults will "rm -rf /var/lib/mysql" on purge, but otherwise
/var/lib/mysql should be treated as read-only by all other packages.

4) Each variant should have maintain its own directory in /var/lib.
Whether that's (eg) /var/lib/mariadb-5.{5,6}/ or /var/lib/mariadb/ is
up to the variants to decide. I imagine that this will depend on
compatibility between versions. I can forsee the same sort of problem we
have at the moment if multiple packages share a directory in /var/lib,
so there should be a further restriction that only one binary package in
the archive at one time may own one of these directories in /var/lib.

5) For automatic migration between variants where this is possible, a
variant's binary package may _read_ from another variant's /var/lib
directory. But it may not write or make any other changes.

Example:

* mysql-5.6 owns /var/lib/mysql-5.6
* The user installs mariadb-10, which will own /var/lib/mariadb-10
* mariadb-10.postinst detects /var/lib/mysql-5.6. It supports automatic
  migration so it copies /var/lib/mariadb-10. The database state is now
  forked.

If the user later wants to switch back to mysql-5.6, he will either
effectively go backwards in time, or he will need to migrate the data
from /var/lib/mariadb-10 back to /var/lib/mysql-5.6. At this point he
gets to choose whether to destroy the old data or to back it up first,
etc.

Common code for help with detecting what variants are in /var/lib, and
perhaps to help the user with migration, could go into mysql-defaults.

> Additionally I would like to know your view on adding MySQL 5.6.19 to
> experimental and trusty as the latest released version. I can initiate
> the work on 5.6.19 if you do not see any blockers.

This sounds fine - though as 5.6 is in Debian experimental and Trusty
universe, perhaps it might be an idea to sort out the /var/lib/mysql
thing first, so that mysql-5.6 follows the new scheme from the start?
I'm not sure though - since 5.6 is already in universe in Trusty, we
probably do want to get the upgrade path right.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20140702/ba8cdc27/attachment.sig>