Package: ftp.debian.org
I am aware that this is a very unusual request, but I feel it is my last resort, so I am doing it anyhow. Please try to understand the problem and suggested solution before dismissing the request. ## Request In the name of avoiding a quality catastrophe, please - remove from the Debian testing/unstable repos the source package and all binary packages of mariadb-10.1 version 1:10.1.29-6 - reset the dak/ftp-system archive database records related to this package so the systems accept 10.1.28-2 and forgets about the newer versions that needed to be reverted - re-introduce last known good version mariadb-10.1 10.1.28-2 ## Motivation I am the primary maintainer of the MariaDB packages in Debian. I foresee a significant quality problem with the current mariadb-10.1 package version 1:10.1.29-6 in Debian (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. If this issues is not fixed, a large amount of existing MariaDB installations will stop working when upgrading from a previous version of Debian to the testing/unstable or next stable version, and users with fresh installations will not be able to install from 3rd party repositories any other versions of MariaDB than this 1:10.1.29-6. The use of 3rd party repositories is very common and breaking all of them I think is unacceptable and against the general sentiment that Debian is supposed to help people get technically empowered and advance society. Also, the epoch in the version is ugly. Personally I am motivated to help Debian because of the ability to create something technically advanced and elegant, and because of how that work potentially helps any human anywhere. If we proceed with this 1:10.1.29-6 then both of those motivations fall off, as this version in counterproductive to both goals. ## Extra motivation why we should not require the whole world to adapt to this "bug" I agree that the Debian policy is sacred, and that we can require the world to follow it wherever somebody does any .deb packaging. The policy changes and heavily discussed and reviewed and all happen because of good reasons. However I don't agree that _any_ decision done by _any_ Debian Developer is something that we can or should require the whole world to adapt to. We have now at hand a mistake done by a single Debian Developer that needs to be fixed before it spreads. The fix is quite unusual (manually modifying dak/ftp records) but not impossible, and from a larger perspective the most elegant fix that can be executed by a single person in a short time to avoid forcing multiple persons to suffer from the bug and forcing people to fix packaging in many places over a period of months or years. ## 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 very for users of Debian (and its derivates) run a newer version of MariaDB which they have installed the MariaDB.org repositories or a PPA or some other 3rd party repository. 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 with version 2). Systems have been designed to support only upgrades. Another scenario is a fresh install of Debian next stable where somebody wants to install mariadb-server version 10.3, but they cannot, since the Debian 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 did the packaging required to introduce MariaDB into Debian official in 2014 and I have since been supplying Debian with frequent MariaDB uploads, while other contributing DD's have come and gone. If the flawed version 1:10.1.29-2 remains in Debian, I will orphan it from my part, because I don't want to have my name associated with the massive breakage that will result when 1:10.1.29-6 or any later versions of that epoch are shipped to users at large in a stable release. 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 Debian repository so that I can continue to fix it with my normal Debian Developer powers. - Otto
