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 <c...@taz.net.au>