Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
otto at ubuntu.com
Sat Mar 10 14:23:10 UTC 2018
Hello Ubuntu QA team!
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
- 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
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
- 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
- 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
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.
More information about the Ubuntu-quality