Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives
robie.basak at ubuntu.com
Thu Mar 15 13:47:39 UTC 2018
Thank you for your efforts in resolving this.
For the record, I'm not on the Ubuntu release or archive admin teams,
but due to my existing involvement in the MySQL/MariaDB packaging team
and in Ubuntu I guess it makes sense for me to get involved.
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.
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.
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.
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
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
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. 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.
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Ubuntu-quality