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

[Otto Kekäläinen]

Hello!

2018-03-17 12:04 GMT+02:00 Adam Conrad <adconrad at ubuntu.com>:
> On Fri, Mar 16, 2018 at 12:35:42AM +0000, Robie Basak wrote:
>> On Fri, Mar 16, 2018 at 12:01:11AM +0200, Otto Kekäläinen wrote:
>>
>> > And keep the epoch forever. No thanks.
>
> Epochs happen.  A lot.  Here's a quick check of my installed packages:
>
> $ dpkg -l | awk '/^i/ {print $3}' | grep '.:' | wc -l
> 415
>
> I understand that there's a certain "elegance" in always making sure
> versions go forward and epochs never happen as a result, but when that
> doesn't happen, life goes on.

Epochs are quite common, yes, but most examples I've looked at have
had so for a valid reason and in a planned way.

Examples:
- xorg-server, ntfs-3g: was 1:.. already since the first upload to Debian
- git-core: use epoch 1 to supersede gitweb-264 package version
- ruby-defaults: introduced epoch to move from version 4.9 to 1.9
- virt-manager: introduced epoch to move from 0.9 to 0.10
- vim: change package version numbering so that new upstream patches
don't generate new source packages

The only case of "oops, nevermind" I saw was in nautilus
(1:3.24.1-0ubuntu1) with changelog entry "set epoch number (which was
added by error)". This package is supposed to be different from
Debian, so the epoch does a sensible function there despite the
changelog entry.

There are however also other cases where the epoch was introduced for
a stupid reason and should have not been done, like the case "add
epoch since upload is rejected with different orig.tar.gz..." in plum
1:2.33.1-0.1

On debian-devel@ there was recently more discussions on stupid epoch
bumps, but it ended up in not trying to stop it. There was a bug
report about forcing epoch bumps through NEW but it got dismissed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860797

> As a side note, this whole "10.1.29+really10.1.28" business could be
> avoided by moving to 10.1.30, which we seem to be shipping in arful's
> security pocket.  I suspect I'm missing context here, but is there a
> reason that .30 isn't suitable (and, if so, should we be informing the
> security team)?

The way forward here I guess is that
1) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860797 or
something similar should be implemented to stop developers form
uploading epochs too easily, as they should happen very rarely and it
cannot be revoked
2) mariadb-10.3 1:10.3.6-1 should be uploaded to Debian to at least
stop all current 10.3 and 10.2 and 10.1.29+ installs from downgrading.
This is the most effective remedy that can be done in this situation
to minimize the fallout.

I might look into uploading mariadb-10.3 if I have energy to debug all
epoch fallout issues in the control file, but it seems unlikely it
would make into Ubuntu 18.04 since freeze and release is upon us.