Request to reset src:mariadb-10.1 to previous known working state in Ubuntu archives

[Robie Basak]

Hi Steve,

Your reply has made me notice a couple of mistakes in my proposal -
thanks. I want to acknowledge them here to minimise confusion for anyone
else reading. I've also illustrated an example of what I think is a
failed migration case below together with a solution.

On Thu, Mar 15, 2018 at 03:38:09PM -0700, Steve Langasek wrote:
> 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.

> On Thu, Mar 15, 2018 at 01:47:39PM +0000, Robie Basak wrote:

> > I suggest that we:

> > [...]

> > 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.

My suggestion of 1:10.1.29-7really10.1.28 can't work because the
upstream version wouldn't match the tarball. Your suggestions of
2:10.1.28-3 or 1:10.1.29+really.10.1.28-1 are correct.

> > 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.

Ah, right. We wouldn't be to lose the "really" until 10.2 or 10.1.30.

[...]

> 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.

10.2.x is in play in upstream's 10.2 apt repository for Artful, for
example. A user who upgrades from there to Bionic will end up going
backwards to 1:10.1.x[1]. To avoid this, I think external repositories
will need to republish 10.2 and 10.3 with an epoch bump to all series,
including for Artful, as well as for Bionic. Then the user will upgrade
to 1:10.2.x while still on Artful, and so apt will then not attempt to
"upgrade" to 1:10.1.x on upgrade to Bionic.

Robie

[1] Or does do-release-upgrade have some magic to prevent this?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20180316/0599cf9a/attachment.sig>