[debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

Norvald H. Ryeng norvald.ryeng at oracle.com
Wed Jan 27 09:32:01 UTC 2016


On Tue, 26 Jan 2016 23:45:59 +0100, Otto Kekäläinen <otto at seravo.fi> wrote:

> Examples of technical arguments I'd prefer to use instead of general
> disgust of Oracle arguments:
>
> - Quality: mysql-5.6 has 135 open bugs despite never being part of a
> Debian release and thus having exposure to the big Debian user masses.
> Some of them are even RC. The package mariadb-10.0 has only 10 bugs,
> which of 5 were filed by myself as TODO items with priority wishlist,
> and it actually ships in Jessie for big audience.

I see 113 bugs in src:mysql-5.6 [1], but, OK, it's the same ballpark. Most  
of those are bugs filed against older MySQL versions. If you instead look  
at mysql-server-5.6 [2], you'll get a more accurate number: 12. Could the  
list be cleaned of old, irrelevant bug reports from MySQL 4.1, 5.0 and 5.1  
packaging? Yes, absolutely. But they're not really bothering us in the  
daily work, so other tasks have been prioritized.

> - Quality: mysql-5.6 ships the same version number
> libmysqlclient.so.18 as 5.5 but the ABI is different and according to
> investigations by Robie Basak going back September 2014 [1] the
> upgrade might break something, and while it is now partially remedied,
> the ABI bump has never been done,

The major version is the same because they were supposed to be compatible.  
However, a small bug squeezed through in a little used feature, and that  
is why they're not fully compatible, and that's what stopped us from  
upgrading to 5.6 in jessie. It was analyzed thoroughly by upstream, and  
the risk of breaking anything is very small. Still, we erred on the safe  
side and didn't upgrade to 5.6 in jessie.

The major number 19 has been reserved for fixing this (which is why MySQL  
5.7 bumps to libmysqlclient.so.20), but it was decided that the downside  
of bumping the version number is greater than the benefits. Basically,  
you'll have to recompile all applications instead of a few that break  
(none of which are in Debian). It's been coordinated with upstream, and  
Debian is free to bump the version number to 19 if wanted.

> the symbols file to track this all
> is missing from the packaging, and there is a Lintian override to keep
> Lintian quiet about the lack of a symbols file [2]

The problem with adding a symbol file is that the library exports more  
symbols than it should, so there's a lot of noise that looks like ABI  
incompatibility, while it isn't if you're looking at the symbols that are  
actually used by clients. The list of exported symbols can be restricted  
in 5.6, but that is definitely something that calls for a major number  
bump, which is why it hasn't been done.

Libmysqlclient in MariaDB has the same problem. There are build options  
that will restrict the list of exported symbols. If you use those, you'll  
get a library that exports a much smaller list of symbols, but without  
bumping the major version of the library, so again you're stuck with  
compatibility issues.

MySQL upstream did a library cleanup in 5.7 which fixed this, so in 5.7  
packaging we can add a symbols file. If we bump the 5.6 library to version  
19, we can do it in 5.6 too.

> - Quality: mysql-5.6 only runs ~600 tests as part of their Debian
> build, while MariaDB has 4000+ tests, making MySQL test coverage much
> smaller than the MariaDB one, thus catching less issues on many of the
> Debian platforms as Oracle MySQL probalby don't test those at all
> in-house.

It was decided at the packaging sprint in London in December 2014 that the  
test runs should be reduced in order to reduce build time in Debian. Also,  
some timing sensitive tests are skipped to avoid spurious failures on VMs.  
This was done after consulting the upstream QA team, and the selected set  
of tests is believed to be enough to uncover bugs that may be introduced  
in packaging. A larger set of tests can be run by setting  
DEB_BUILD_OPTIONS to "fulltest", which will run more or less the same  
tests that are run per push upstream (still not the entire test suite).

Upstream would of course not mind if the full test suite with thousands of  
test was run after each build, but it would take many, many hours.

Regards,

Norvald H. Ryeng

[1]  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mysql-5.6;ordering=normal;archive=0;repeatmerged=0#_0_6_0
[2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=mysql-server-5.6



More information about the pkg-mysql-maint mailing list