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

Otto Kekäläinen otto at
Sat Mar 31 17:33:53 UTC 2018


2018-03-17 12:04 GMT+02:00 Adam Conrad <adconrad at>:
> 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.

- 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

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:

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

More information about the Ubuntu-quality mailing list