Hello, On Thu, Mar 15, 2018 at 01:47:39PM +0000, Robie Basak wrote:
> On Sat, Mar 10, 2018 at 04:23:10PM +0200, Otto Kekäläinen wrote: > > ## 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 > Unfortunately, to the best of my knowledge we don't ever try to make > this kind of revert in the archive because of the knock-on effects it'll > have everywhere else. I believe both Debian and Ubuntu will hold the > same opinion on this: now that the epoch bump has been published, we > will have to live with it. The Debian archive simply does not support rolling version numbers backwards, and while it would be possible to do so in Launchpad, this doesn't change the behavior of the package manager clients. There is no way to make the whole system "forget" about newer versions if those versions are already deployed to end installs, which will be the case for at least some pre-release consumers of bionic. So no, I don't think we are going to remove the existing packages from the bionic archive and roll back the version number. We would also not add an Ubuntu revision solely to keep the package from syncing from Debian. At the moment, we are past Feature Freeze (and thus past Debian Import Freeze), so the package would not be automatically updated anyway until after the 18.04 release; and a delta added to block autosyncing does not communicate when it would again be acceptable to sync (or why it isn't). A more suitable path forward, that works for both Debian and Ubuntu: - The maintainer uploads to Debian unstable whatever is the correct and releasable version of mariadb, with a version number >= the current versions there (options: 2:10.1.28-3; 1:10.1.29+really.10.1.28-1) - The maintainer requests a sync of this new version into Ubuntu bionic - Everything moves forward. > I suggest that we: > 1. Ask the Ubuntu archive admins to remove src:mariadb-10.2 (10.2.7-1) > from the archive. I see that Debian has already done this, so Debian and > Ubuntu will be the same. This is now done. (I took this thread as an excuse to process recent Debian removals in bionic; no further paperwork required.) > 2. Re-publish exactly your known good version mariadb-10.1 10.1.28-2 but > bump the version string to 1:10.1.29-7really10.1.28. The binaries that > will build from this will all have version 1:10.1.29-7really10.1.28 > which is higher than all binaries previously published, so should > publish fine. I believe this would be appropriate to fix the mess in > Debian too. Therefore you can do this in Debian and we can sync it over > in Ubuntu. This doesn't need to wait for step 1, but it might be wise to > have the archive admins review this entire plan first. This corresponds to my suggestion above. > 3. Once the dust has settled, you can prepare a 1:10.1.28-8 or a > 1:10.1.29-1 (if that exists) or a 1:10.2.7-1 at your leisure, and they > can go into Bionic according to the normal freeze requirements. Again, > you can continue uploading to Debian and we can sync over to Ubuntu as > appropriate. 1:10.1.28-8 is not an option in this scenario because 1:10.1.29-6 is already published. But in general, yes. > Consequences: > 4. Users already on the broken mariadb-10.2 will end up "upgrading" to > mariadb-10.1, which isn't a supported data migration path as you point > out. They will need to fix their systems manually - but as they were > using pre-release software, I think this is acceptable even if > unfortunate. There is no broken mariadb-10.2 in Ubuntu; this package never built from source (except on s390x, and was rejected at binary new). So there is no upgrade issue for mariadb-10.2 for us. > 5. Everyone shipping MariaDB packages, including upstream, PPAs, etc, > will need to follow the epoch bump in order for everything to work > smoothly. This is, AIUI, unavoidable now. Yes, once an epoch is in the wild in Debian or Ubuntu, it's irreversible. Others will simply need to follow suit. > If a PPA does not do this, then users will end up downgraded, with a > failed data migration and therefore broken. This is again unfortunate but > I think acceptable: this is the risk of following a PPA. It's not clear to me that there is any risk of failed data migration, since the versions involved are 10.1.29 and 10.1.28 - 10.2.7 is not in play. > Options I'm deliberately opining against: > 6. Going backwards in version numbers. AIUI, Launchpad will not permit > this anyway and nor will Debian ftpmasters. > 7. Directly fixing mariadb-10.2 without reverting mariadb-10.1 first by > bumping it. Since Bionic is past feature freeze and mariadb-10.2 has > always been broken, I think it's prudent to get the archive into a > releaseable state first, and only then looking at bumping major > versions. IMHO (but this is the release team's decision and not mine), > we should consider 10.2 to have missed feature freeze since it has > always been broken. Making 10.2 or 10.3 work in the archive for Bionic > now should be breaking feature freeze so should follow the usual > exception process. In any case, re-publishing mariadb-10.1 as I suggest > should be comparatively trivial and will not impact any move to 10.2 or > 10.3 whether in this cycle or in the future. > Does this plan (steps 1 to 3 above) seem reasonable to everyone? +1 from me. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
