On Fri, Feb 15, 2013 at 2:10 PM "Jan-Frode Myklebust" wrote:
On Thu, Feb 14, 2013 at 10:17:00AM -0500, Tom Lane wrote:
>
> The way this worked in the past (and still does on RHEL and some
> other
> distros) is that MySQL AB provided RPMs named "MySQL",
> "MySQL-server",
> etc, which simply conflicted with the Red Hat-supplied packages
> named
> "mysql", "mysql-server", etc. Perhaps it would be best to
continue
> that
> naming tradition, ie establish a new Oracle-maintained Fedora
> package
> named "MySQL", instead of figuring out how to transition
> maintainership
> of the "mysql" packages. This would give us some more wiggle room
> about
> managing the transition --- in particular, it's hard to see how we
> manage Obsoletes/Provides linkages in any sane fashion if the
> "mysql"
> package name continues in use. I think we're going to have to end
> up
> with a design in which "mysql" becomes essentially a virtual
> Provides
> name.
>
I'm quite amazed at how MariaDB is allowed to do this takeover of
mysql
in fedora. Why can't MariaDB use it's own configuration files, own
datadir, own socket, own binary names, etc.. ? I'm no Oracle or
Mysql
fan, but as far as I see it Oracle/mysql is the original branch of
the
mysql project, and I think a competing fork should do it's best not
to
conflict with it. No effort not to conflict seems to be happening
here,
rather the opposite.
Upstream chose the way of drop-in replacement, which means that the same API including
file names was actually a feature. Why we don't do it differently in Fedora is obvious
-- we don't want to differ from upstream.
What happens when MariaDB and Mysql start diverging? Will it be
impossible to have a client that connects to both mysql and mariadb
servers ?
Most probably not. I doubt that if these projects start diverge in the future,
incompatible changes in client-server protocol will be desired changes. I believe the
opposite would be true -- which is compatibility on this layer will be still important.
Honza