Re: Debian part of a version number when epoch is bumped
On Wed, 14 Feb 2018 at 15:33:45 -0500, Michael Stone wrote:
> The fundamental problem was that it's impossible to
> predict that a future package would have an older version of the software
> with a newer name. Whether that's done with an epoch that (horrors!) won't
> go away or because someone creates a crazy version string that obfuscates
> what's being done (yay?), the unpredictable breakage is the same.
When using an epoch, all future versions have to use the (same or higher)
epoch, all future version references (Depends/Breaks/etc.) have to use
it, and whenever someone forgets to include it in a version reference
there is, as you said, unpredictable breakage.
When using a mangled version number (2+really1) the same unpredictable
breakage exists, but only for a finite time. glib2.0 had the popular
"oops, that was meant to have gone to experimental" mistake during
wheezy development, and has a +really version number in wheezy; but this
weirdness could be discarded next time a new upstream version was ready
to go into testing, and glib2.0 in jessie is back to being a normal
version number. dbus had the same thing during buster development, but
got a new upstream version (greater than the one I uploaded to the wrong
suite) not long after, so that mistake never even appeared in a release.
That seems a lot less bad than epochs.
(Of course, it would be better still if maintainers never made mistakes,
but we have considerable anecdotal evidence that this is an unrealistic
assumption.)
If this class of mistake is going to lead to unpredictable breakage
either way, I'd much prefer it to be temporary rather than permanent.
> The solution isn't to get rid of epochs, the solution is to not create
> packages which contain older versions of software with newer names.
As much as I'd love to have it somehow be impossible to upload to
unstable when you meant experimental, I'm not sure how to get there
from here. Maintainers do make mistakes, and the closest I can think of
to having automation to catch this mistake would be to autoreject the
Lintian tag experimental-to-unstable-without-comment, but you can see from
<https://lintian.debian.org/tags/experimental-to-unstable-without-comment.html>,
how many false positives that tag has.
Acknowledging that mistakes happen, and making sure they can be reverted,
seems a useful design principle (analogous to the GUI design principle of
offering an undo operation instead of an "are you sure?" prompt). We can
revert every other brown-paper-bag bug with a re-upload with a higher
revision number (or artificially-slightly-higher upstream version
number in the rarer case where the orig.tar.* is bad); but because
version numbers in a suite aren't allowed to go backwards, uploading
an upstream branch into a suite for which it is not yet ready can't be
reverted without escalating more-significant parts of the version number,
either via an epoch or the +really hack.
smcv
Reply to: