<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><br>
      Hi Robie/ Everyone,<br>
      <br>
      Thanks for your response which makes it easier to sort out the
      priority list at this moment. As I get it, I am placing the tasks
      in order of priority below:<br>
      <ol>
        <li>Upgrade Paths:<br>
        </li>
        <ol>
          <li>Separation of data directory.<br>
          </li>
          <li>mysql-defaults package should contain common functionality
            and own data directory as well.</li>
          <li>Handling upgrade scenarios from old format to new format
            that depends on mysql-defaults.<br>
          </li>
        </ol>
        <li>Get remaining delta from 5.5 into 5.6 packaging source.</li>
        <li>Import latest released version of 5.6 into experimental and
          trusty universe.</li>
        <li>Get 5.6 as default in Debian testing and Ubuntu 14.10.</li>
      </ol>
      <p>For now, as you said already, lets discuss on upgrade paths
        first.<br>
      </p>
      <p>You proposal looks promising but I suspect that users might
        find it difficult to handle change of data directory location
        who wish continue with MySQL. Moreover, MySQL 5.5 data dir can
        be directly taken over by MySQL 5.6 using simple mysql_upgrade
        utility as it is being done at this moment. There will no need
        for having separate /var/lib/mysql-5.6 data dir for reason of
        binary incompatibility.<br>
      </p>
      <p>Another trouble that I see with forking the data dir is related
        to the size of data dir. In case user has large data dir that
        goes into GBs or even TBs then the copy would take noticeable
        amount of time. We might need to show them a progress status/
        bar and also handle situations like copy of data dir ending
        midway with an error.<br>
      </p>
      <p>I would like to present a slight modification to the proposal
        with help of controlled links. This would keep /var/lib/mysql
        intact owned by the MySQL 5.x series keeping things simpler for
        all existing users who wish to continue with MySQL. In case a
        user wants to install another fork of MySQL then during
        installation fork.{pre,post}inst would detect existing MySQL 5.6
        and would ask if the user wishes to fork the data dir or start
        fresh.<br>
      </p>
      <ol>
        <li>Fresh start with blank data dir.</li>
        <ol>
          <li>Uninstall MySQL 5.x as regular removal.</li>
          <li>Create fork specific data dir /var/lib/fork or
            /var/lib/fork-version in case there can be compatibility
            issues.</li>
          <li>Move /var/lib/mysql to /var/lib/mysql.backup (snapshot)<br>
          </li>
          <li>Create link /var/lib/mysql pointing to /var/lib/fork</li>
          <li>Install fork as regular installation.<br>
          </li>
        </ol>
      </ol>
      <p>The user can decide after installation to remove, backup or
        keep /var/lib/mysql.backup. Fork would be able to access data
        dir directly at /var/lib/fork. Same will remain accessible via
        /var/lib/mysql if needed for administration purpose by user
        scripts.<br>
      </p>
      <ol start="2">
        <li>Fork the data dir.</li>
        <ol>
          <li>Uninstall MySQL 5.x as regular removal.</li>
          <li>Move /var/lib/mysql to /var/lib/fork and optionally copy
            /var/lib/fork to /var/lib/mysql.backup (snapshot)<br>
          </li>
          <li>Create link /var/lib/mysql pointing to /var/lib/fork</li>
          <li>Install fork as regular installation.</li>
        </ol>
      </ol>
      <p>Again, user can work on mysql.backup later if he decides so,
        otherwise the default operations only move data dir that should
        be quick and more manageable operation.<br>
      </p>
      <p>Please let me know your views on the modifications suggested
        above to the initial proposal.<br>
      </p>
      <p>Regards,<br>
        Akhil<br>
      </p>
      On Wednesday 02 July 2014 09:32 PM, Robie Basak wrote:<br>
    </div>
    <blockquote cite="mid:20140702160228.GU17765@mal.justgohome.co.uk"
      type="cite">
      <pre wrap="">Akhil,

Sorry for the slow response.

On Tue, Jun 17, 2014 at 11:21:25AM +0530, Akhil Mohan wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap=""> 2. Separation of data directory and common packaging scripts as part of
    an independent package.
</pre>
      </blockquote>
      <pre wrap="">
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?

</pre>
      <blockquote type="cite">
        <pre wrap=""> 3. Giving each binary incompatible MySQL variant its own data directory
    at /var/lib/<fork>.
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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
</pre>
    </blockquote>
    <br>
  </body>
</html>