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

[Craig Sanders]

On Wed, Oct 26, 2016 at 04:52:38AM +0200, Clint Byrum wrote:
> The point of the stable release is security updates with minimal impact.

well, no.  that's ONE of its points, not THE point.

Another point is to refrain from breaking existing systems - that's at
least as important as security updates, even if for no other reason than
that you should be able to trust your distro to not arbitrarily break
your system on upgrade either due to carelessness or for some misguided
and just-plain-wrong claim that breaking your system is for your own good.


> > [ re: dump to text and restore ]
>
> You can definitely do that as a user. But automating it just isn't
> something anybody has had time to do and feel good about it, given
> that we're talking about peoples' data.

yet allowing mariadb to use the same data directory as mysql (even
though it's not completely RW compatible with mysql) is somehow
acceptable?

automated export and import is safe. blindly using incompatible binary
data files is not.


the postgresql packages manage to successfully - flawlessly - upgrade
even through binary-incompatible major releases and have done so for
many years. any mysql -> mariadb transition should be handled at least
as well as that.  it's not impossible, it's not even "too hard".


craig

--
craig sanders 

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

[Craig Sanders]

On Wed, Oct 26, 2016 at 04:43:53AM +0200, Clint Byrum wrote:
> > [ using /dev/tcp in bash ]
>
> That seems like a gross oversimplification of what works extremely well
> today. mysqladmin actually understands mysql's protocol, and can verify
> that it is up and fully functional. Listening doesn't mean responding,
> or ready for clients.

wow. you spotted that a grossly simple substitute was a gross
over-simplification. nobody can accuse you of being unobservant.


> One would hope mariadb's client package provides a similar thing, and
> maybe we could just depend on the virtual package.

if mariadb's client can serve in place of mysql's then of course
it makes sense to use whichever one is available.


did you have anything actually useful - and preferably not completely
obvious - to add, or are you just mouthing off because you can?

craig

--
craig sanders 

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

[Clint Byrum]

Excerpts from Craig Sanders's message of 2016-10-26 12:10:49 +1100:
> On Tue, Oct 25, 2016 at 01:09:23PM +0100, Robie Basak wrote:
> > I agree with you, but the release team have made their decision against our
> > wishes. There's no point arguing with us. We know.
> 
> since when does the release team tell maintainers what they're allowed
> to package?  or what solutions they're allowed to come up with for
> easily-forseeable problems?
> 

The point of the stable release is security updates with minimal impact.
The security team has decided MySQL makes that exceedingly difficult
because of the CVE's reported against it without full disclosure. They
are ultimately responsible for those updates (though maintainers from
Oracle have helped quite a bit) and they do not want to carry the burden
anymore. They also seem to think our users don't like those CVE's,
though I never saw any real evidence of that.

> > > 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.
> >
> > This does not exist, and currently nobody has the time to work on this.  I
> > believe MySQL->MariaDB works right now, but the reverse direction certainly
> > doesn't. Users should take backups before upgrading.
> 
> the problem is binary db-file compatibility, so the obvious method would be to
> dump to text from mysql, possibly do some minor fixups to the text dump with
> sed or pœrl if required, restore into mariadb.
> 
> and the reverse for converting from mariadb to mysql.
> 

You can definitely do that as a user. But automating it just isn't
something anybody has had time to do and feel good about it, given that
we're talking about peoples' data.

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

[Clint Byrum]

Excerpts from Craig Sanders's message of 2016-10-26 12:56:43 +1100:
> On Tue, Oct 25, 2016 at 06:42:11AM -0700, Lars Tangvald wrote:
> 
> > SysV and upstart scripts use mysqladmin (which is in the client) to verify
> > that the server is running. 5.7 has some inbuilt support for systemd, so for
> > systemd at least it's not needed.
> 
> pgrep (or even telnet to port 3306) would probably be better.
> 
> but neither of those are Essential, and neither is netstat, so to avoid
> another dependency, using bash's /dev/tcp built-in would probably be better.
> mysql's init.d script is already bash rather than sh, and this is a bash
> feature which has existed since version 2.04 (although it was disabled in
> debian until around 2009 IIRC)
> 
> some google results on the topic:
> 
> http://hacktux.com/bash/socket
> http://www.linuxjournal.com/content/more-using-bashs-built-devtcp-file-tcpip
> 
> probably don't need to get a meaningfule result, just check to see there's
> something listening on port 3306 (or whatever's defined in my.cnf)
> 
> #! /bin/bash
> 
> ( exec 3<>/dev/tcp/localhost/3306 ) >& /dev/null
> echo $?
> 
> wrapped in a subshell to avoid spamming stderr if nothing's listening.

That seems like a gross oversimplification of what works extremely well
today. mysqladmin actually understands mysql's protocol, and can verify
that it is up and fully functional. Listening doesn't mean responding,
or ready for clients.

One would hope mariadb's client package provides a similar thing, and
maybe we could just depend on the virtual package.