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

[Craig Sanders]

On Wed, Oct 26, 2016 at 07:38:01AM +0200, Clint Byrum wrote:
> Thanks for reminding me that the internet is full of useless people.

if you don't want to get slapped down for rudeness then don't start out
by being obnoxious. you got the response you provoked, no more and no less.

> Good luck getting help.

it's not I that needs help.

craig

--
craig sanders 

Bug#842011: [debian-mysql] Bug#842011: 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 15:22:27 +1100:
> 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?

Thanks for reminding me that the internet is full of useless people.

Good luck getting help.

Bug#842011: [debian-mysql] Bug#842011: 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 15:31:58 +1100:
> 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.
> 

Sorry, that was the 'minimal impact' part of my reply. But there are
times where the behavior is insecure and the distro must "break" things
by securing things. A user that disagrees with that policy should
disable automatic security updates.

Also I think we can agree that "thou shalt not break" is a rule for
updating packages in a stable release. Upgrades from release to release
are allowed to break stuff, as long as the user is adequately informed.

> > > [ 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?
> 

I've never liked it, and I actually think it's part of MariaDB's
strategy to be a one-way street. I don't know why it's being allowed to
persist.

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

Safe in all cases?

Also this is asking to keep 3 copies of every database around for a
time (export file, new database, old database). That's fine for little
ones, but what about a 2TB data warehouse that might take a week to
export and import?

> 
> 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".
> 

That's a project that is in control of both ends of the upgrade. MariaDB
is a one way street, and MySQL truly does not care if they can't
re-import an export from MariaDB. Also, in the case of stretch, there's
no MySQL to go back to.. so there's no point in automating that path for
the sole purpose of stable update users. Unstable users can and should
be careful when switching.

IMO that's why we should have just left both in. They're not even close to
being the same code base, and the compatibility matrix is getting smaller
and smaller. There are plenty of maintainers and the response time on
those security updates has been adequate from all maintainers. But,
the security team disagrees, and thus, we have this situation.