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

[Michael Stone <mstone@debian.org>]

On Wed, Feb 14, 2018 at 12:54:05PM -0800, Russ Allbery wrote:
> 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).

I don't think you'd need to change the package metadata for this, just 
change the comparison rules. I'm not entirely sure what the semantics 
should be, though--a simple depends >= is easy, but what about conflicts 
and breaks with <<? I agree that it's probably more trouble than it's 
worth. 

Another way to think of it is that the epoch should really be evaluated 
as part of the package name rather than the version string--it's 
basically a mechanism to avoid renaming a package for purely aesthetic 
reasons.

Mike Stone