Re: Debian part of a version number when epoch is bumped

[Russ Allbery <rra@debian.org>]

Michael Stone <mstone@debian.org> writes:

> That doesn't matter. 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. 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.

Not that this is probably easily fixable at this point, but mulling on
this a bit, I think it's because we actually have two version orderings
that we're compressing into one ordering.

We want to do two things here:

* Give a package a larger version number so that the archive knows that it
  replaces the previous version of the package and so that clients know
  that this package should be installed in preference to the previous
  version.

* Express versioned dependencies in other packages, allowing you to say
  that you need at least version 1.8 of a package and 1.6 will not
  suffice.

These seem like the same thing, but they subtly aren't.  There are times
when we want to tell the archive to replace version 1.8 with 1.6, and tell
all apt clients to install 1.6 in preference to 1.8, but do not want that
package to satisfy a version dependency of >= 1.8.

Since there are two goals, a more correct implementation would be to split
these into two versions.  The simplest would be to have an integer
"version epoch" field in the package metadata separate from the version
number.  So instead of:

Version: 1.8-1

Version: 1:1.6-1

you'd have:

Version: 1.8-1

Version: 1.6-1
Epoch: 1

We then could implement the separate semantics: only the version field
would be used for interpackage dependencies, so 1.6-1 with epoch 1 would
not satisfy >= 1.8 dependencies, but DAK and apt clients would know that
any package with epoch 1 supersedes packages with no epoch for archive and
default installation purposes.

Of course, getting to that from where we are now may be substantially more
trouble than it's worth, and it would necessarily be a very slow rollout
process (and there are still issues with unique filenames).

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>