[debian-mysql] Bug#842011: Bug#842011: default-mysql-client forces removal of mysql-server* and mysql-client*

[Craig Sanders]

On Tue, Oct 25, 2016 at 10:54:56AM +0100, Robie Basak wrote:
> Hi Craig,

Hi

> On Tue, Oct 25, 2016 at 08:01:26PM +1100, Craig Sanders wrote:
> > it's somewhat surprising that a package called default-mysql-client
> > should force the removal of both mysql-client and mysql-server
> > packages.
>
> Please could you explain your use case? What are you trying to do at a
> high level and why?

upgrade mythtv.

on further investigation, it seems likely that the mythtv-common package
(from the deb-multimedia repo) is at fault here.

every package in debian itself that depends on default-mysql-client has
an alternate dependency on virtual-mysql-client.

the most recent version of mythtv-common doesn't, it just depends on
default-mysql-client.  I've posted about this to the dmo-discuss mailing
list, so hopefully it will get sorted out there soon enough (in the
meantime, i've used equivs to work around it)


it still seems very surprising to me that a package called
default-MYSQL-client would force the removal of mysql-client* and
mysql-server*

> > mariadb is NOT a drop-in replacement for mysql.
>
> It does, however, take over various binary paths, so the equivalent
> (server<->server, client<->client) packages must conflict, or the
> MariaDB packaging needs to rename all the "mysql" names to "mariadb"
> names, or the MySQL packaging needs to stop using any "mysql" names,
> or we need extreme update-alternatives work. I don't see any other
> options.

IMO іf it can't be sorted out with alternatives, then it should be a
completely separate package. and other packages that need a mysql-like db
should depend on mysql or mariadb or either with 'mysql | mariadb'.

> Separately, MySQL will be leaving testing shortly, so I'm surprised
> that you care. See bug 837615.

i run sid, not testing, although that makes little difference.

i care because i run programs that use mysql, i don't have the time or
the inclination to find out if they work with mariadb too. they probably
do, but i don't want to find out the hard way that they're not.

i have no strong preferences about mysql vs mariadb one way or the
other (and from what i've read, mariadb IS the superior alternative - i
use postgresql for things i write myself), it just happens that what i
already have installed works for the tasks I use it for (myth, asterisk,
wordpress, a few others), and i already have more than enough yaks of my
own to shave.


having mariadb be the default for new installations is perfectly
reasonable, as long as people can chose to install mysql instead. but
forcing it on systems that have been running mysql for years is not at
all reasonable, it would be quite easy to break your existing database -
and possibly have no way to fix/revert the problem if there are no more
mysql packages available.


> Forcing the removal of mysql-client* is by design, so this is
> "wontfix" without further discussion.

i suspect you'll get lots of bug reports about this when ѕtretch becomes
the new stable.  people don't like surprises.  they especially don't
like surprises with their databases.

if this is the plan then there really needs to be a foolproof,
automated, thorougly tested migration script.  and even then it should
still be easy to back out and revert to mysql.

> If you want to take this further then please could you file a separate
> bug for that ("mysql-client-* conflicts with mariadb-client-*), so we
> can distinguish between the different root causes? It will immediately
> be a wontfix but I welcome technically feasible arguments to have that
> changed.

what i care about is the surprising outcome of having mysql-server (and
mysql-client) uninstalled when i think i'm upgrading a mysql package,
because mysql is in the package's name.

if debian is dropping all support for mysql, then mariadb should just
have *mariadb* package names, and not pretend to be mysql when it isn't.


craig

--
craig sanders <cas at taz.net.au>