Hello Ubuntu QA team!
## Request In the name of avoiding a quality catastrophe, please - remove from the Ubuntu Bionic repos the source package and all binary packages of mariadb-10.1 version 1:10.1.29-6 and all remnants of mariadb-10.2 - re-introduce last known good version mariadb-10.1 10.1.28-2 - add an Ubuntu revision so the package stops syncing from Debian - reset the Ubuntu archive database records related to this package so the systems accept 10.1.28-2 and forgets about the newer versions ## Motivation I am the primary maintainer of the MariaDB packages in Debian and Ubuntu. I foresee a significant quality problem with the current mariadb-10.1 package version 1:10.1.29-6 in Ubuntu (which I did not create) and I am asking your help to get it reverted to the last known good version, which is mariadb-10.1 version 10.1.28-2. There was a series of misguided uploads of mariadb-10.1 and mariadb-10.2 in November 2017 by another Debian Developer, who had good intentions, but ended up causing a lot of havoc. I have discussed the incident with him privately and he is unlikely to do any more bad uploads of the mariadb-* packages. Normally MariaDB packaging fixes are done first in Debian and then flow to Ubuntu, but as the Ubuntu 18.04 LTS release is imminent, and this is not yet solved in Debian, I seek to get it fixed directly in Ubuntu as soon as possible, in time before the next release. If this issues is not fixed, a large amount of existing MariaDB installations will stop working when upgrading from a previous version of Ubuntu to the 18.04 version, and users with fresh installations will not be able to install from 3rd party repositories or PPA's any other versions of MariaDB this 1:10.1.29-6, and this version of MariaDB in Ubuntu 18.04 will stop getting security updates. ## Technical details - mariadb-10.1 10.1.28-2 is the last known good version of the package - In mariadb-10.1 10.1.29-1 quality decreased, because certain non-applying patches were removed instead of updated, which causes build failures on certain Debian architectures. Also the mariadb-test-packages were removed from the packaging without a solid motivation. - At this point in time badly prepared mariadb-10.2 packages were uploaded, which made the QA systems for this package itself raise tens of flags, and in addition caused dependent packages to fail in many ways. - mariadb-10.1 with epoch version 1:10.1.29-2 was uploaded to Debian in an attempt to revert the bad mariadb-10.2 upload. This was the worst mistake made in the series of mistakes. - An epoch in the version string was introduced against the Debian policy to force 10.1 to override 10.2. - Then a series of revision uploads from -2 up until -6 where made trying to fix build issues, basically using the Debian archive proper as a testbed for things like make flags. Doing a git revert now and uploading a fixed 10.1.29-7 does not help here, since the epoch was introduced, and the epoch itself is a bug that should be reverted. It is fairly common for users of Ubuntu LTS versions to run a newer version of MariaDB which they have installed manually or from packages from a PPA or the MariaDB.org repositories. Because of the epoch, anybody running for example mariadb-server version 10.3.x will have their packages either break (leaving dpkg and the entire system in a broken state) or it will downgrade the binaries to mariadb-server 1:10.1.29-2, and a 10.1 binary will naturally not be able to start using binary data files from a future 10.3 version. MariaDB (nor any other database system) is not able to downgrade data-files in place, which is quite natural when you think about it (developers of version 1 cannot predict how a data file will look like several years into the future). Systems have been designed to support only upgrades. Another scenario is a fresh install of Ubuntu 18.04 where somebody wants to install mariadb-server version 10.3, but they cannot, since the Ubuntu repositories contain a newer version (1:10.1.29-2 > 10.3.x). Package managers will simply refuse to "downgrade". There are also many other scenarios where the packages will break in upgrade/install and not behave as users expect or how packagers have originally designed the packages should behave. Note also that in the MariaDB and MySQL packages there exists both mariadb-server (unversioned) and mariadb-server-10.1 (with a version) so that sysadmins can choose to pin their systems to a certain MariaDB version and thus have a more predictable behavior on system upgrades and updates. Now with the epoch in the version this logic breaks down as well and unexpected things will happen. Last, but not least, I would like to point out that I have been supplying Ubuntu with frequent MariaDB security uploads since Ubuntu 14.04 until Ubuntu 17.10 (and I still prepare all mariadb-5.5 updates for Ubuntu 14.04). If the flawed version 1:10.1.29-2 remains in Ubuntu 18.04 LTS, I will not prepare any security updates for it anymore, because I don't want to have my name associated with the massive breakage that will result when 1:10.1.29-2 or any later versions of that epoch are shipped to users. I am sorry I didn't follow up earlier on the uploads done by the other Debian Developer and I didn't catch these problems early on. I know the request I now make is very unusual, but this is my last resort to get this package reverted back to a working version in the Ubuntu repository so that I can continue to fix it with my normal Debian Developer and Ubuntu Developer powers. I hope the QA team will take this notification seriously, and help in the effort of getting the request above carried out, so that Ubuntu can avoid having certain breakage of a widely used package. - Otto -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
