Hello! 2018-03-17 12:04 GMT+02:00 Adam Conrad <adcon...@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. -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality