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

[Otto Kekäläinen]

Thanks Robie for your comment. Comments to them below:

2018-03-15 15:47 GMT+02:00 Robie Basak <robie.basak at ubuntu.com>:
..
> 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 don't think it has unacceptable knock-on effects if reverted. On the
contrary, if not reverted, the knock-on effects will be massive.

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

Yes, Ubuntu should follow Debian there.

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

For the record, I will not have my name associated with any
1:10.1.29-x versions, and I will not respond to bug reports from
people running that version, or any later version that inherits its
problems.

There is quite a lot of challenges with packaging such a big package
already, but I remain keen in working on it because it results in a
technically beautiful result and as open source if benefits a very
large crowd of users. If the technology has permanently ugly elements
and the crowd is an angry one, I don't see the point in continuing the
effort.

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

And keep the epoch forever. No thanks.

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

Yes, correct. And this is already happening and reverting to 10.1.28-1
would make no difference for them in short term, but in long term they
would get 10.3 etc nicely installed and running.

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

I don't think PPA = unstable crap. Nor that we can or should assume
that all 3rd party repositories are temporary or unstable or something
like that. There are perfectly valid 3rd party repositories our there
that are used in production systems. Requiring the world to adapt to
this situation I think is a very self-centric approach and maybe even
against the Ubuntu spirit.

I think Debian unstable, Debian testing and all Ubuntu alpha and beta
releases imply to users that they might have bugs and might change.
Currently this bug has only lived in such pockets and thus it would
make sense to fix it before it gets out in a release labeled stable.

> Options I'm deliberately opining against:
>
> 6. Going backwards in version numbers. AIUI, Launchpad will not permit
> this anyway and nor will Debian ftpmasters.

Underlying is a database that can have records manually fixed to close
this "bug". I do understand that mu request here is exceptional,
though.

I could go around the systems by changing the name of the package, but
that would be a hack as stupid as introducing the epoch in the first
place. My hope is for reverting the package to the state before bad
uploads.

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

Yes, that is why I suggest reverting to 10.1.28-1 which at least
worked well. It will be a separate discussion if you want to have 10.3
in this late, but as Jeremy asked for it, I said I can commit to
delivering it, assuming of course that the show-stopper bug for all
future packaging is resolved first.

- Otto