[debian-mysql] percona vs. mariadb

[Steven Ayre]

On 14 March 2013 22:00, Clint Byrum <spamaps at debian.org> wrote:

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


+1

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.

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.

-Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20130315/039cae70/attachment-0001.html>