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

[Guillem Jover <guillem@debian.org>]

Hi!

Given that other parts of the original thread have started to repeat
the same that has been discussed in previous referenced discussions,
or even within this thread iteration, I've sat down and written a
dpkg FAQ entry:

  <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F>

This subthread though, prompted me to come up with something new
though. :)

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

This only covers the revert case, for which epochs are really the
wrong tool. To me this looks like the equivalent of using nukes as
a town planning strategy. :)

An epoch states that the previous version-line is no longer valid
and cannot be used or relied on anymore going forward.

> 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.

For a revert the only things we really need is to make the archive
accept lower versions, and for the package managers to accept a version
downgrade as the correct "upgrade" path. In this case preserving all
the versioned dependencies/checks intact is what we'd want anyway.

> 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

I don't think splitting this into a new field would fix much, it would
just complicate things. We already had the packaging revision in
separate fields (Package_Revision, Package-Revision, Revision) long time
ago, and it got eventually folded in. :)

I think there are two ways to fix the revert problem properly:

  * Create a new archive suite with some suite-specific metadata denoting
    that whatever appears in this suite has a higher pin than anything
    installed, and can thus downgrade packages (following the example
    of the existing NotAutomatic repo fields). You could then have:

      pkg-a_1.0-1 (sid) → pkg-a_2.0-1 (sid) → pkg-a_1.0-2 (sid-revert)

    Of course one problem is that this might perhaps require for
    example new apt sources entries.

  * Add a new field, which specifies this is a revert and as such a
    downgrade is expected. Then the package managers would know this
    is the correct "upgrade" path. For example, say:

       Version: 1.0-1

       Version: 2.0-1

       Version: 2.0-2

       Version: 1.0-2
       Reverts: 2.0-2

    Perhaps, even allowing relationships in the field, dunno:

       Reverts: >= 2.0-1, <= 2.0-2

Thanks,
Guillem