[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

Reply to: