Bug#732878: Add MariaDB as an alternative dependency

[Thomas Goirand]

Package: automysqlbackup
Severity: wishlist
MariaDB is an drop in replacement for MySQL. As MariaDB has just
landed in Debian unstable it would be a good time to include it in the
dependencies as an alternative to MySQL.
Please change in the debian/control any occurences of mysql-server and
mysql-client to "mariadb-server | mysql-server" and "mariadb-client |
mysql-client".
This way systems that have MariaDB installed instead of MySQL can use
this package without problems. While MariaDB is at the moment only in
Debian unstable, some users might have installed it from mariadb.org
or other sources to jessie or wheezy, so it does not hurt if this
package has these dependencies updated for older Debian releases too.
This is a very quick and safe change to do, and there is no urgency to
upload the package just for this small thing. Just update the
dependency (or suggest or recommends) lines in the debian/control file
and let the change propagate when there is something else to push too.
http://packages.debian.org/search?keywords=mariadb&searchon=names&suite=all&section=all
Thanks!
- Otto

Hi Otto,

First of all, thanks so much for maintaining MariaDB within Debian.

Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

Adding debian-devel@, as I think it should be discussed more broadly.

Cheers,

Thomas Goirand (zigo)

P.S: Do you know if the MariaDB package in Sid has the capability to run
in cluster, like for Galera?

[Vincent Bernat]

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

Maybe MariaDB wants to be the "default" MySQL implementation?

[Clint Byrum]

Post by Vincent Bernat

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

Maybe MariaDB wants to be the "default" MySQL implementation?

MariaDB is not MySQL, so this is not really what you mean. Also I'd ask
that you suggest why you think there should be a default, and why you
think that "MySQL" should not be the default "MySQL".

[Ben Hutchings]

Post by Clint Byrum

Post by Vincent Bernat

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

Maybe MariaDB wants to be the "default" MySQL implementation?

MariaDB is not MySQL, so this is not really what you mean. Also I'd ask
that you suggest why you think there should be a default, and why you
think that "MySQL" should not be the default "MySQL".

Similarly,

wodim is not cdrecord
LibreOffice is not OpenOffice.org
Iceweasel is not Firefox
etc.

so clearly we should never have implemented an automatic transition from
one to the other...

Ben.

[Clint Byrum]

Post by Ben Hutchings

Post by Clint Byrum

Post by Vincent Bernat

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

Maybe MariaDB wants to be the "default" MySQL implementation?

MariaDB is not MySQL, so this is not really what you mean. Also I'd ask
that you suggest why you think there should be a default, and why you
think that "MySQL" should not be the default "MySQL".

Similarly,
wodim is not cdrecord
LibreOffice is not OpenOffice.org
Iceweasel is not Firefox
etc.
so clearly we should never have implemented an automatic transition from
one to the other...

As far as I know, we are not planning any such automatic transition from
MySQL to MariaDB. They will both remain in Debian as long as there are
parties available to maintain them. Percona Server will also be arriving
soon, and now I see talk of Galera enabled MySQL variants as well.

This is quite a bit different from those three desktop programs you
mentioned.

[Ben Hutchings]

Post by Clint Byrum

Post by Ben Hutchings

Post by Clint Byrum

Post by Vincent Bernat

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

Maybe MariaDB wants to be the "default" MySQL implementation?

MariaDB is not MySQL, so this is not really what you mean. Also I'd ask
that you suggest why you think there should be a default, and why you
think that "MySQL" should not be the default "MySQL".

Similarly,
wodim is not cdrecord
LibreOffice is not OpenOffice.org
Iceweasel is not Firefox
etc.
so clearly we should never have implemented an automatic transition from
one to the other...

As far as I know, we are not planning any such automatic transition from
MySQL to MariaDB. They will both remain in Debian as long as there are
parties available to maintain them. Percona Server will also be arriving
soon, and now I see talk of Galera enabled MySQL variants as well.

This strikes me as an incredibly bad idea. There will be four times the
security issues to fix, more work for maintainers of dependent packages,
and confusion for users.

Post by Clint Byrum
This is quite a bit different from those three desktop programs you
mentioned.

Yes, but perhaps it should not be.

Ben.

[Clint Byrum]

Post by Ben Hutchings

Post by Clint Byrum

Post by Ben Hutchings

Post by Clint Byrum

Post by Vincent Bernat

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

Maybe MariaDB wants to be the "default" MySQL implementation?

MariaDB is not MySQL, so this is not really what you mean. Also I'd ask
that you suggest why you think there should be a default, and why you
think that "MySQL" should not be the default "MySQL".

Similarly,
wodim is not cdrecord
LibreOffice is not OpenOffice.org
Iceweasel is not Firefox
etc.
so clearly we should never have implemented an automatic transition from
one to the other...

As far as I know, we are not planning any such automatic transition from
MySQL to MariaDB. They will both remain in Debian as long as there are
parties available to maintain them. Percona Server will also be arriving
soon, and now I see talk of Galera enabled MySQL variants as well.

This strikes me as an incredibly bad idea. There will be four times the
security issues to fix, more work for maintainers of dependent packages,
and confusion for users.

I agree 100%. However, this was not Debian's idea, it was the MySQL
community's idea. The MySQL community tried to correct it with Drizzle,
a project I was involved with. MySQL was forked, cleaned up, and made
entirely modular so that folk wanting to do interesting things could
make plugins not forks. Drizzle, sadly, has largely stopped development,
IMO because it changed the SQL dialect making it hard to adopt.

So we have forks. And forks suck. But that is how MySQL's little inbred
family works. And that is why I am pretty adamant that upstreams be
involved or I will not spend what little time I do have for Debian on
keeping their forks in Debian.

Post by Ben Hutchings

Post by Clint Byrum
This is quite a bit different from those three desktop programs you
mentioned.

Yes, but perhaps it should not be.

I'm not sure you can make a distributed database solution the same
as a browser, which does not need to directly share and serve data in
real time across nodes with other browsers as a primary function. The
reasons for these forks are not mostly political like libreoffice
vs. openoffice. There are deep technical differences that matter a lot
to the users and developers of each fork.

[Philipp Kern]

Post by Clint Byrum
So we have forks. And forks suck. But that is how MySQL's little inbred
family works. And that is why I am pretty adamant that upstreams be
involved or I will not spend what little time I do have for Debian on
keeping their forks in Debian.

[
]

Post by Clint Byrum
I'm not sure you can make a distributed database solution the same
as a browser, which does not need to directly share and serve data in
real time across nodes with other browsers as a primary function. The
reasons for these forks are not mostly political like libreoffice
vs. openoffice. There are deep technical differences that matter a lot
to the users and developers of each fork.

OTOH every introduction of a new fork will increase the burden on us to
support this "solution" for its technical differences. People will tell
us that we cannot remove fork X because their data is all in the format
of fork X. If they move away from being drop-in replacements, this
will become quite annoying I think (e.g. eglibc is a drop-in
replacement, egcs was basically a drop-in replacement, etc.).

Kind regards
Philipp Kern

[Clint Byrum]

Post by Philipp Kern

Post by Clint Byrum
So we have forks. And forks suck. But that is how MySQL's little inbred
family works. And that is why I am pretty adamant that upstreams be
involved or I will not spend what little time I do have for Debian on
keeping their forks in Debian.

[…]

Post by Clint Byrum
I'm not sure you can make a distributed database solution the same
as a browser, which does not need to directly share and serve data in
real time across nodes with other browsers as a primary function. The
reasons for these forks are not mostly political like libreoffice
vs. openoffice. There are deep technical differences that matter a lot
to the users and developers of each fork.

OTOH every introduction of a new fork will increase the burden on us to
support this "solution" for its technical differences. People will tell
us that we cannot remove fork X because their data is all in the format
of fork X. If they move away from being drop-in replacements, this
will become quite annoying I think (e.g. eglibc is a drop-in
replacement, egcs was basically a drop-in replacement, etc.).

Totally agree that once they go from drop-in replacements to full forks
the situation gets more urgent for one to dominate and thus kill off
the others. It seems to me that MariaDB 10 will force that situation,
as it may introduce on-disk incompatibility. When it does, then we will
have to get rid of some of the breaks/replaces relationships and move
data storage from /var/lib/mysql to /var/lib/mariadb.

To be clear, my point isn't to be anti-MariaDB or pro-MySQL. I am
pro-Debian-user. Debian users are not served if we push them onto MariaDB
when MySQL remains viable and its main code contributor (Oracle) remains
committed to helping maintain it in Debian. Likewise, some MariaDB users
have stepped up and thus it is also going to land in Debian. And Percona
is working hard on getting their packages ready for Debian as well.

So my point is, who are we to choose one if the authors and users of
others are excited to maintain the others?

[Thomas Goirand]

Post by Clint Byrum

Post by Philipp Kern

Post by Clint Byrum
So we have forks. And forks suck. But that is how MySQL's little inbred
family works. And that is why I am pretty adamant that upstreams be
involved or I will not spend what little time I do have for Debian on
keeping their forks in Debian.

[…]

Post by Clint Byrum
I'm not sure you can make a distributed database solution the same
as a browser, which does not need to directly share and serve data in
real time across nodes with other browsers as a primary function. The
reasons for these forks are not mostly political like libreoffice
vs. openoffice. There are deep technical differences that matter a lot
to the users and developers of each fork.

OTOH every introduction of a new fork will increase the burden on us to
support this "solution" for its technical differences. People will tell
us that we cannot remove fork X because their data is all in the format
of fork X. If they move away from being drop-in replacements, this
will become quite annoying I think (e.g. eglibc is a drop-in
replacement, egcs was basically a drop-in replacement, etc.).

Totally agree that once they go from drop-in replacements to full forks
the situation gets more urgent for one to dominate and thus kill off
the others. It seems to me that MariaDB 10 will force that situation,
as it may introduce on-disk incompatibility. When it does, then we will
have to get rid of some of the breaks/replaces relationships and move
data storage from /var/lib/mysql to /var/lib/mariadb.
To be clear, my point isn't to be anti-MariaDB or pro-MySQL. I am
pro-Debian-user. Debian users are not served if we push them onto MariaDB
when MySQL remains viable and its main code contributor (Oracle) remains
committed to helping maintain it in Debian. Likewise, some MariaDB users
have stepped up and thus it is also going to land in Debian. And Percona
is working hard on getting their packages ready for Debian as well.
So my point is, who are we to choose one if the authors and users of
others are excited to maintain the others?

I totally agree that the situation sux for everyone: final users, people
willing to contribute to MySQL [1] server (they have to contribute to 4
projects now?), the Debian MySQL [1] maintainers, and finally anyone who
maintains something that uses MySQL [1] (package maintainers or upstream
who simply use the client).

All this is quite sad.

It'd be nice if there was ways to avoid some of the collateral damage
we'll have in Debian. Like avoiding to force adding mariadb-client in
all MySQL-using package would be a nice thing to do. Avoiding to first
do mysql-client | mariadb-client, and THEN migrate to the virtual
package would be even better. I'm just not sure what's the solution here
though... :(

Cheers,

Thomas

[1] Please understand MySQL at large in this context: I really mean
every forks of it.

P.S: Thanks Clint, for your valuable contributions to this thread.

[Vincent Bernat]

Post by Clint Byrum

Post by Vincent Bernat

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

Maybe MariaDB wants to be the "default" MySQL implementation?

MariaDB is not MySQL, so this is not really what you mean. Also I'd ask
that you suggest why you think there should be a default, and why you
think that "MySQL" should not be the default "MySQL".

I am saying this because the bug reports about adding support for
MariaDB were asking for mariadb-client | mysql-client and not
mysql-client | mariadb-client. My question is genuine, I really don't
know. Do we plan to transition away from MySQL to MariaDB?

[Clint Byrum]

Post by Vincent Bernat

Post by Clint Byrum

Post by Vincent Bernat

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

Maybe MariaDB wants to be the "default" MySQL implementation?

MariaDB is not MySQL, so this is not really what you mean. Also I'd ask
that you suggest why you think there should be a default, and why you
think that "MySQL" should not be the default "MySQL".

I am saying this because the bug reports about adding support for
MariaDB were asking for mariadb-client | mysql-client and not
mysql-client | mariadb-client. My question is genuine, I really don't
know. Do we plan to transition away from MySQL to MariaDB?

No such plan is under way. I am one of the few people maintaining MySQL,
but others have recently stepped up to get us onto git, to get MySQL
5.6 ready, and to do general work, so MySQL seems like it may remain in
Debian. As long as it does, there is no "automatic transition". They are
forked, and more so than ever with MariaDB 10, so we should just treat
them as such.

[Thomas Goirand]

Post by Clint Byrum

Post by Vincent Bernat

Post by Clint Byrum

Post by Vincent Bernat

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

Maybe MariaDB wants to be the "default" MySQL implementation?

MariaDB is not MySQL, so this is not really what you mean. Also I'd ask
that you suggest why you think there should be a default, and why you
think that "MySQL" should not be the default "MySQL".

I am saying this because the bug reports about adding support for
MariaDB were asking for mariadb-client | mysql-client and not
mysql-client | mariadb-client. My question is genuine, I really don't
know. Do we plan to transition away from MySQL to MariaDB?

No such plan is under way. I am one of the few people maintaining MySQL,
but others have recently stepped up to get us onto git, to get MySQL
5.6 ready, and to do general work, so MySQL seems like it may remain in
Debian. As long as it does, there is no "automatic transition". They are
forked, and more so than ever with MariaDB 10, so we should just treat
them as such.

After all these replies, I'm still not sure what to do with my package.
Should I add mariadb-client as possible dependency? If, like it seems,
we get 4 different types of "MySQL compatible" servers (MySQL itself,
MariaDB, and both with the Percona patch making Galera from MySQL or for
MariaDB), does it makes sense to add dependency for all of them, in
absolutely all the packages in the Debian archive?

In other words, will I have to do something like:
Depends: mysql-client | mariadb-client | mysql-galera-client |
mariadb-galera-client

or is the client for the galera and non-galera the same?

Thoughts anyone?

Thomas

P.S: Please reply specifically on what implies this for packages that
depend on MySQL/MariaDB, and *not* about what's the plan for the servers
in Debian, which have already been discussed. If you wish to discuss it,
please do so in a new thread, or at least change the subject line.

[Clint Byrum]

Post by Thomas Goirand

Post by Clint Byrum

Post by Vincent Bernat

Post by Clint Byrum

Post by Vincent Bernat

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

Maybe MariaDB wants to be the "default" MySQL implementation?

MariaDB is not MySQL, so this is not really what you mean. Also I'd ask
that you suggest why you think there should be a default, and why you
think that "MySQL" should not be the default "MySQL".

I am saying this because the bug reports about adding support for
MariaDB were asking for mariadb-client | mysql-client and not
mysql-client | mariadb-client. My question is genuine, I really don't
know. Do we plan to transition away from MySQL to MariaDB?

No such plan is under way. I am one of the few people maintaining MySQL,
but others have recently stepped up to get us onto git, to get MySQL
5.6 ready, and to do general work, so MySQL seems like it may remain in
Debian. As long as it does, there is no "automatic transition". They are
forked, and more so than ever with MariaDB 10, so we should just treat
them as such.

After all these replies, I'm still not sure what to do with my package.
Should I add mariadb-client as possible dependency? If, like it seems,
we get 4 different types of "MySQL compatible" servers (MySQL itself,
MariaDB, and both with the Percona patch making Galera from MySQL or for
MariaDB), does it makes sense to add dependency for all of them, in
absolutely all the packages in the Debian archive?
Depends: mysql-client | mariadb-client | mysql-galera-client |
mariadb-galera-client

If we don't have a virtual-mysql-client that can guarantee a package
which provides /usr/bin/mysql as an alternative, then we should aim at that.

For you, mysql-client will work fine. You would only need mariadb-client
if you want to use a specific feature of mariadb-client. If they do
conflict/break/replace each-other (I can't remember if they do or not),
then you will need the "or" relationships until we provide you a proper
virtual package.

Post by Thomas Goirand
or is the client for the galera and non-galera the same?

They all will speak mysql's network protocol, probably until the end of
time. I imagine some will add features.

[David Moreno]

Post by Clint Byrum
I am one of the few people maintaining MySQL,

And thanks for doing so :)

[Otto Kekäläinen]

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

Currently the package contains "Provides: virtual-mysql-server" but I
guess this needs to be re-evaluated in the packaging team and the
rationale documented better, as I have already forgot why we ended up
with what we have now..

Post by Thomas Goirand
P.S: Do you know if the MariaDB package in Sid has the capability to run
in cluster, like for Galera?

No, but I might package MariaDB Galera Cluster later if I have time
and energy for additional packages. However before that I'll do
MariaDB 10.0 (Debian now only got 5.5).

[Marcin Kulisz]

snip

Post by Otto Kekäläinen

Post by Thomas Goirand
P.S: Do you know if the MariaDB package in Sid has the capability to run
in cluster, like for Galera?

No, but I might package MariaDB Galera Cluster later if I have time
and energy for additional packages. However before that I'll do
MariaDB 10.0 (Debian now only got 5.5).

Hi Otto,
why not to provide by default Galera enabled version and just omit none-galera
one? Galera is happy enough to run as single machine and if you want cluster
you will just have to change 1 line in config to achieve it.

Don't you think this is going to be slightly better solution (1 pkg to
maintain & 1 pkg in repo called mariadb)?

[Otto Kekäläinen]

Hello,

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

We discussed this on the pkg-maint-mysql list and the recommended policy is now:

All packages that at the moment depend directly on mysql-client should
instead have something like:

Depends: the-one-they-tested-with | virtual-mysql-client
(or Suggests or Recommends)

At the moment in unstable the packages mysql-server-5.5 and
mariadb-server-5.5 have
Provides: mysql-virtual-server

and mysql-client-5-5 and mariadb-client-5.5 have
Provides: mysql-virtual-client

Later when other versions are uploaded to Debian (e.g. MySQL 5.6,
MariaDB 10, Percona etc) they will include the same provides as long
as they are compatible enough with MySQL 5.5 to be
drop-in-replacements.

Does this sound OK?

[Thomas Goirand]

Post by Otto Kekäläinen
Hello,

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

All packages that at the moment depend directly on mysql-client should
Depends: the-one-they-tested-with | virtual-mysql-client
(or Suggests or Recommends)
At the moment in unstable the packages mysql-server-5.5 and
mariadb-server-5.5 have
Provides: mysql-virtual-server
and mysql-client-5-5 and mariadb-client-5.5 have
Provides: mysql-virtual-client
Later when other versions are uploaded to Debian (e.g. MySQL 5.6,
MariaDB 10, Percona etc) they will include the same provides as long
as they are compatible enough with MySQL 5.5 to be
drop-in-replacements.
Does this sound OK?

Hi,

This sounds much much better than listing each and every *-client
package indeed.

Thomas

[Otto Kekäläinen]

Post by Otto Kekäläinen
All packages that at the moment depend directly on mysql-client should
Depends: the-one-they-tested-with | virtual-mysql-client
(or Suggests or Recommends)
At the moment in unstable the packages mysql-server-5.5 and
mariadb-server-5.5 have
Provides: mysql-virtual-server
and mysql-client-5-5 and mariadb-client-5.5 have
Provides: mysql-virtual-client
Later when other versions are uploaded to Debian (e.g. MySQL 5.6,
MariaDB 10, Percona etc) they will include the same provides as long
as they are compatible enough with MySQL 5.5 to be
drop-in-replacements.
Does this sound OK?

Just for the record, I've written down now this policy at
https://wiki.debian.org/Teams/MySQL/virtual-mysql-server and it is now
in effect as there was no other contersuggestions, and both the MySQL
packages and MariaDB packages in Debian already abide to this policy.
--
Otto Kekäläinen
[phone]
http://seravo.fi/

[olivier sallou]

Post by Otto Kekäläinen

Post by Otto Kekäläinen
We discussed this on the pkg-maint-mysql list and the recommended policy
All packages that at the moment depend directly on mysql-client should
Depends: the-one-they-tested-with | virtual-mysql-client
(or Suggests or Recommends)

Do you know if libmysql-java is compatible with MariaDB ? I see no
libmariadb-java for the moment in archive.
I suppose there will be one as MariaDb propose Java driver on its web site.
But will it follow the same rule with a kinda libvirtual-mysql-java ?

Olivier

Post by Otto Kekäläinen

Post by Otto Kekäläinen
At the moment in unstable the packages mysql-server-5.5 and
mariadb-server-5.5 have
Provides: mysql-virtual-server
and mysql-client-5-5 and mariadb-client-5.5 have
Provides: mysql-virtual-client
Later when other versions are uploaded to Debian (e.g. MySQL 5.6,
MariaDB 10, Percona etc) they will include the same provides as long
as they are compatible enough with MySQL 5.5 to be
drop-in-replacements.
Does this sound OK?

Just for the record, I've written down now this policy at
https://wiki.debian.org/Teams/MySQL/virtual-mysql-server and it is now
in effect as there was no other contersuggestions, and both the MySQL
packages and MariaDB packages in Debian already abide to this policy.
--
Otto Kekäläinen
[phone]
http://seravo.fi/
--
with a subject of "unsubscribe". Trouble? Contact

[Luca Capello]

Hi there!

Post by Otto Kekäläinen

Post by Thomas Goirand
Don't you think it would be more reasonable if the mariadb-client
contained a Provides: mysql-client, rather than changing each and every
software dependency in Debian?

All packages that at the moment depend directly on mysql-client should
Depends: the-one-they-tested-with | virtual-mysql-client

^^^^^^^^^^^^^^^^^^^^

Post by Otto Kekäläinen
(or Suggests or Recommends)
At the moment in unstable the packages mysql-server-5.5 and
mariadb-server-5.5 have
Provides: mysql-virtual-server

^^^^^^^^^^^^^^^^^^^^

Post by Otto Kekäläinen
and mysql-client-5-5 and mariadb-client-5.5 have
Provides: mysql-virtual-client

^^^^^^^^^^^^^^^^^^^^
While doing the necessary changes for #732879 for Bacula, I found that
the above names mismatch: which are the correct one? The same confusion
is on the Debian wiki:

<https://wiki.debian.org/Teams/MySQL/virtual-mysql-server?action=recall&rev=2>

Moreover, I suppose the MySQL team use the virtual packages privately as
per Debian Policy "§ 3.6 Virtual packages", otherwise please ask for the
inclusion in that document:

<https://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual_pkg>

All packages should use virtual package names where appropriate, and
arrange to create new ones if necessary. They should not use virtual
package names (except privately, amongst a cooperating group of
packages) unless they have been agreed upon and appear in the list of
virtual package names. (See also Virtual packages - Provides, Section
7.5)

As a final note, AFAIK no other (virtual or not) package contains the
"virtual" name in it (except for the old java-virtual-machine or other
packages for obvious reasons, like virtualbox). I guess in this case
the different choice was driven by the fact that we already have "real"
package names for mysql-[server|client]. However, I could not find any
reasoning in the pkg-mysql-maint@ mailing list, which reminds me of the
question Thomas asked at the beginning of this bug ;-)

Thx, bye,
Gismo / Luca