<br><div class="gmail_quote">On 14 March 2013 22:00, Clint Byrum <span dir="ltr"><<a href="mailto:spamaps@debian.org" target="_blank">spamaps@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Excerpts from Otto Kekäläinen's message of 2013-03-13 15:41:20 -0700:<br>
<div class="im">> Hello,<br>
><br>
> 2013/3/7 Bjoern Boschman <<a href="mailto:bjoern@boschman.de">bjoern@boschman.de</a>>:<br>
> >> We should just ship the same major.minor release of all of them if<br>
> >> they're going to share /etc/mysql/my.cnf.<br>
> >><br>
> >> I'd prefer, though, that they didn't if at all possible. If they must,<br>
> >> this probably means having them conflict and provide so that incompatible<br>
> >> options don't cause issues.<br>
> >><br>
> ><br>
> > I totally aggree that different sql-server branches must not share those<br>
> > data!<br>
><br>
> At least at the moment when MariaDB and MySQL are binary-compatible,<br>
> they should share the same data. That makes it easy for admins to<br>
> switch servers. Compare the situation to packages nginx-light and<br>
> nginx-full: same conf files, but different binaries and conflicts each<br>
> other, so both binaries can't be installed at once.<br>
><br>
<br>
</div>Easy is not the goal. Simple, resilient, reliable. Not easy.<br>
<br>
/var/lib/mysql for mysql. /var/lib/mariadb for mariadb. If an admin<br>
wants to migrate between the two, I suggest they think that through<br>
*very* clearly and use the method that makes the most sense for them<br>
(symlinks.. bind mounts, manual mv'ing files/dirs).<br>
<br>
The package is there to deliver a working DB, not to solve all system<br>
admin tasks.<br>
<div class="im"><br>
> At some point in the future, if they really diverge from each other,<br>
> they could adapt separate configs (compare how httd providers Apache<br>
> and Nginx are packaged in Debian). But I think these kind of diverges<br>
> are initiated in the upstream project, and not designed nor maintained<br>
> by downstream packagers.<br>
><br>
<br>
</div>IMO they must use separate configs now.</blockquote><div><br></div><div>+1</div><div><br></div><div>Even if the databases are binary compatible that doesn't mean the config files are. Different projects might be based on different versions and that could mean that even some standard config options may have been deprecated/removed/renamed between versions which would prevent them sharing data. For example language vs lc_messages_dir in the 5.1->5.5 transition.</div>

<div><br></div><div>Even if Debian were to distribute the variants itself and keep on top of it that way, if the infrastructure is being put in to allow 3rd parties (Percona etc) to neatly integrate additional variants (which seems a good idea to minimise the Debian workload with so many) then you'd still get in that situation very easily. Much easier not to share config files.</div>

<div><br></div><div>-Steve</div></div>