36

I have just noticed that Wine (and a number of other packages) have shifted their versioning scheme to something like:

1:1.6.2-0ubuntu3

I understand everything after the 1:... But what does the 1: refer to?

It doesn't seem to mirror the major version. Looking at a list of pending upgrades, there are versions like: 2:4.1.3... and there are plenty of packages without the #: prefix.

What's going on?

4
  • it seems to be Ubuntu specific, packages.debian.org/sid/wine does not have this prefix Apr 1, 2014 at 10:52
  • It's new for Wine in Ubuntu too (as of 14.04) but other packages like python3-uno (in Ubuntu and in Debian) have the prefix consistently.
    – Oli
    Apr 1, 2014 at 10:55
  • Indeed, I've found the answer on superuser Apr 1, 2014 at 10:56
  • @Oli It's not new for wine, it was always there, but because its value was 0 all the time until 14.04, it was omitted to be written in the version string. So, you can think at all those plenty of packages without the #: prefix as they contain in fact 0:. See the answers which you have received to understand better. Aug 1, 2014 at 18:18

3 Answers 3

31

From man deb-version:

NAME
       deb-version - Debian package version number format

SYNOPSIS
       [epoch:]upstream-version[-debian-revision]

DESCRIPTION
       Version  numbers as used for Debian binary and source packages
       consist of three components. These are:

       epoch  This is a single (generally  small)  unsigned  integer.
              It  may  be omitted, in which case zero is assumed.  If
              it is omitted then the upstream-version may not contain
              any colons.

              It is provided to allow mistakes in the version numbers
              of older versions of a package, and  also  a  package's
              previous version numbering schemes, to be left behind.

So, that extra number (in your case 1) refers to the epoch component which may be omitted in which case 0 is assumed. And so, if you see a version string which looks like 1.6.2-0ubuntu3 you can think that in fact it looks like 0:1.6.2-0ubuntu3. How is this helpful and how does this comes: It is provided to allow mistakes in the version numbers of older versions of a package, and also a package's previous version numbering schemes, to be left behind . To understand better, take a closer look at the following explanatory paragraphs from Debian Policy Manual - Control files and their fields:

When comparing two version numbers, first the epoch of each are compared, then the upstream_version if epoch is equal, and then debian_revision if upstream_version is also equal. epoch is compared numerically.

And:

Note that the purpose of epochs is to allow us to leave behind mistakes in version numbering, and to cope with situations where the version numbering scheme changes. It is not intended to cope with version numbers containing strings of letters which the package management system cannot interpret (such as ALPHA or pre-), or with silly orderings.

0
14

This is the epoch. It overrides the version in determining which of two packages is newer:

From the deb-version man page:

   epoch  This is a single (generally small) unsigned integer.  It may  be
          omitted,  in  which case zero is assumed.  If it is omitted then
          the upstream-version may not contain any colons.

          It is provided to allow mistakes in the version numbers of older
          versions  of  a  package,  and also a package's previous version
          numbering schemes, to be left behind.

Source

2

Concrete example

Here's a concrete example to maximize your understanding speed.

Suppose that the original package had versions:

  • 2019.1
  • 2019.2
  • 1.2 (original package decided to randomly change the release naming scheme)
  • 1.3

Then Debian treats those as:

  • 0:2019.1 (commonly known simply as 2019.1 because the leading 0: can be omitted)
  • 0:2019.2
  • 1:1.2 (Debian bumps the epoch from 0 to 1 to deal with the new naming scheme)
  • 1:1.3

This way we can still know the version order clearly from the package version string, or be able to differentiate them at all if the original package makes the cardinal sin of actually reusing an old name release in the new scheme.

Can you imagine the type of Hellish things that Debian developers have had to accommodate for? :-)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .