Bug#565308: MariaDB in Debian proper?
Lionel Elie Mamane <lionel@mamane.lu> writes:
>> The main issue that needs solving is to let MySQL and MariaDB packages
>> co-exist in the same repository.
>
> So they _do_ need some more work :)
Yes. The existing packages are not suitable as-is for inclusion in Debian
because of this issue.
>> The problem is that there are other packages that have versioned
>> "depends:" on MySQL packages, eg. libdbd-mysql-perl on
>> libmysqlclient15off.
>
> Note in passing: thinking of upload to Debian proper, that is now
> libmysqlclient16.
Yes, you are right, MariaDB 5.1 and MySQL 5.1 have libmysqlclient16,
libmysqlclient15 is from MySQL 5.0.
>> So it is not possible for MariaDB to satisfy this dependency with a
>> "provides:", even though MariaDB does include an alternative
>> libmysqlclient.so.
>
>> What has been discussed is to solve this by introducing virtual packages for
>> libmysqlclient15off and similar packages; these would then depend: on
>> mysql-xxx|mariadb-xxx packages. This requires changes to MySQL packages as
>> well as to MariaDB packages.
>
> These would have to be real, but empty (dependency-only) packages, not
> virtual packages.
You are right, sorry for using the wrong terminology.
> I implicitly understand that, as far as predictable, the
> libmysqlclient.so.NN from MariaDB will stay binary-compatible with the
> one from MySQL.
Correct.
> I'm not entirely convinced; as far as *desirable* is it truly
> impossible that one would wish to install both side by side,
> e.g. because they have diverged in features, or for testing before
> switching?
You are right. Packaging MariaDB so that it does not conflict with MySQL is an
alternative approach.
> The default port is not a problem: this is configurable, or they can
> be configured to listen on different IPs. The same for the datadir,
> socket, etc.
> I expect the executable name, man pages, etc can rather easily be
> renamed.
It is possible to change the port, rename files, etc. The problem is that
there are many other programs that connect to MySQL, run the client binaries,
link the libraries. It seems to me it will become more difficult to make all
these programs able to use MariaDB as an alternative, and easy to end up so
that MariaDB users will need to have also some mysql packages installed to
satisfy dependencies. Or maybe that can all be handled with empty
(dependency-only) packages, /etc/alternatives, and similar mechanisms?
Another issue is that the data directories would need to be different (by
default...), so upgrading from MySQL -> MariaDB (or the other way round) would
require manual action to migrate the data. Currently, we make a lot of effort
to ensure that `apt-get install mariadb-server` will automatically migrate,
including migrating the data directory (and we run automated upgrade tests of
this scenario on all Debian and Ubuntu versions for every push to our code
trees).
I guess the bottom line is that we are very much in the mindset that MariaDB
is a plug-in replacement of MySQL that is 100% backward compatible (and will
stay so), so it makes most sense for us to package it the same way that MySQL
5.1 replaces MySQL 5.0.
On the other hand, as you say, installing side-by-side would make other use
cases simpler.
> Only one of the *client* libraries can be installed and active and the
> same time, that much seems correct.
I suppose, unless something like /etc/alternatives symlinks can be used (don't
know if this is possible).
> The server executables seems not to be linked against any
> MySQL-specific library, so that's not a problem. Unless it maybe
> dlopen()s them?
Agree, should not be a problem (the server dlopen()s some .so plugins, but
those can easily be kept separate).
> So, it seems *possible* to me to arrange things so that the servers
> can both be installed at the same time, and with some configuration
> left to the admin, running at the same time.
Agree. It is not the path that I would select, however in the end I think it
is up to the Debian developers to decide.
- Kristian.
Reply to: