On Tue, Oct 08, 2019 at 11:31:14AM -0400, Michael Krieger wrote: > This is because technically 10.3 is not officially supported by innotop, and > so it uses old legacy code which returns incorrect results. > > While innotop doesn't get support 10.3, us shipping innotop with MariaDB 10.3 > means it should really work with it. It is substantially close to 10.1/10.2 > to include it in the ways that works as opposed to using outdated code meant > for older versions of MySQL. > > Ideally, innotop should be updated to include official 10.3 support. Until > the developer does that, this will at least make innotop usable on Debian > Buster 10.
FWIW, we removed innotop from "the other side" in the MySQL packaging. We faced similar breakages, and it seemed wrong to ship innotop inside the MySQL packaging as it's a separate upstream that comes from a different upstream organisation and breakages like this don't seem infrequent. IMHO, if we ship it at all, innotop should be shipped as a separate Debian source package with appropriate declared dependencies and autopkgtests. This current breakage might be an opportunity to fix that. This would also permit people who care about innotop to become nominated maintainers and they would then be able to look after its compatibility against MySQL/MariaDB in the same way that Debian handles transitions for other reverse dependencies, with all the usual tooling, process and reporting, which might make everything run smoother. I don't intend for this comment to block any particular approach though - I'm just offering what I hope is a useful perspective.
signature.asc
Description: PGP signature
