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

[Robie Basak]

On Fri, Mar 16, 2018 at 12:01:11AM +0200, Otto Kekäläinen wrote:

[I've rearranged the quote ordering to bring common topics together]

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

[...]

> And keep the epoch forever. No thanks.

[...]

> 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 appreciate that we all wish the epoch bump didn't happen. Reverting,
even if it were advisable, is not my decision. I think the implications
are worse than you think - for example for derivatives using automation
to follow along. In any case, I believe that this type of request has
been refused in the past for worse situations than this. I don't think
it'll happen, so to make progress I think we need to accept this and
deal with it.

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

What are the problems that will be inherited by keeping the epoch? How
do you think these will be prevented by reverting the epoch bump?

I think that we all understand that you weren't involved in the creating
this situation and we don't associate you with causing the problem. I
think it can be made clear via the changelog in future uploads what you
are and are not responsible for. Nobody can force you to prepare any
upload of course, and we will remain grateful for all the work you've
done already if you feel compelled to stop participating.

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

The situation we're in now is exactly why using PPAs and other third
party apt repositories can be risky for users.

>                                      Requiring the world to adapt to
> this situation I think is a very self-centric approach and maybe even
> against the Ubuntu spirit.

Requiring the world to adapt to this situation *is a consequence of
apt's design*, and not of any decision we're making today. The problem
is that external package repositories overload the distribution
archive's package and version namespace. The only sane way of dealing
with this is to ask (and/or expect) them to keep up. This is
unfortunate, but it's the consequence of the way that apt works, which
is why it is dangerous to use any external apt repository or PPA that
does not keep up or refuses to keep up. There is no other reasonable
solution. Going backwards in package versions causes other problems.

Regardless, it's easy for all external repositories to deal with this.
They just need to match the epoch bump. I don't think this is too
onerous.

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

Testers still have a reasonable expectation that upgrading will, after
release, bring them up to the stable release package versions. Going
backwards in versions will break this. What if, for example, a tester
has a broken mysqld from src:mariadb-10.1 1:10.1.29-6, has disabled the
service manually, but still relies on libmariadbclient18 1:10.1.29-6? A
future security update after Bionic's release given version
10.1.something will never be received.

There are also other consumers of package publications. Raspbian's
Autoforwardportergit comes to mind. I don't know if it will be affected.
It doesn't matter to my point, since you'd have to find every instance
of this type of consumption and verify that it won't break by package
versions going backwards before you can claim that reverting would be a
less worse option. On the other hand, accepting the epoch bump and only
publishing versions higher than already published, including in external
repositories, will not confound the problem in this way.

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

Right - so let's just accept the epoch bump and carry on.

Remember that apt skips versions. Once we have superseded the broken
package version by uploading one with a higher version, users who never
had the broken version installed, such as users who didn't use Bionic
during development, will upgrade "past" the broken one and so their
systems will never be broken. AFAICT, there are only two consequential
differences between this and your proposal:

1) Already-broken users will have to manually downgrade in your proposal
whereas in my proposal already-broken users will be upgraded
automatically. If you care about that difference, we could arrange for
the preinst to record if upgrading from the known-broken version by
touching a file somewhere, so the fact that the user once had the broken
version installed can be permanently recorded. Then we can act on that
information in maintainer scripts automatically (eg. warn the user,
refuse to file a bug, go into the freeze mode we've designed for data
migration problems, etc). Recording the fact would have to be done on
the next upload, as the information will be lost after the first package
upgrade otherwise. But just this part is trivial to implement.

2) The existing epoch bump will remain in my proposal, and external
repositories publishing packages for Bionic, or Debian testing, unstable
and/or buster will have to follow along. I've addressed this above.

I understand that the epoch bump is ugly and feels unclean. I don't
think there's any way around it, though, without creating more problems
than it will solve.
-------------- 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-quality/attachments/20180316/a09c58d4/attachment-0001.sig>