1

For deploying our server software, we use .deb files, created with the standard Debian packaging scripts.

We're in the process of changing our version numbers. They were 1.$SHA, e.g. 1.b07be5a5; now they're a bit more semver, e.g. 2.52.1+e0ce8a81 or 2.53.0-pre+0cdb5e4.dirty.

This results in a warning:

Previous package version was Debian native whilst new version is not

What does this mean? Should we care?

Roger Lipscombe
  • 89,048
  • 55
  • 235
  • 380

1 Answers1

2

Yes, you should care.

If your packages are Debian native (i.e. you build them for Debian and the package's version number is also the version number of each release) then you should stick to a version numbering scheme which preserves this.

If your packages are not Debian native, you should number them accordingly.

Debian package version numbers have the general format

(epoch:)upstreamversion-packageversion(...fluff)

where the dash is significant (and the epoch and trailing stuff are optional); so 1-2 signifies upstream version 1 and the 2 says this is the second Debian package of this upstream version.

Your package versioning scheme where apparently you use a dash for something else is not compatible with this scheme, and needs to be changed one way or another to avoid accidents. Concretely, if the string after -pre is a random hash, you could end up in a situation where an older hash is regarded by dpkg as newer because 1-pre+012new is numerically less than 1-pre+987old.

A concrete suggestion would be to embed a human-readable date and index number before the hash so you have a simple way to avoid this. Then 2.52.1-20191211.01~e0ce8a81 and 2.53.0-20191211.01pre+0cdb5e4.dirty contain the information you want but still sort correctly if there are packages like 2.52.1-20191211.02~adeadbeef or 2.53.0-20191211.02pre+000000 published on the same day with hashes which coincidentally sort lower than those of a previous package from the same day.

If your examples are roughly illustrative, the epoch prefix is not mandatory, but adding it would be a good signal to consumers that these version numbers follow a different convention than those in the previous epoch. (When you switch numbering schemes from 11, 12, 13 to 1.0.15 you really have to add an epoch number in front, resulting in 1:1.0.15 instead.) If you don't put an explicit epoch number, the implied epoch number is zero. So to repeat the previous examples with an epoch number 1 added in front, you'd end up with 1:2.52.1-20191211.01~e0ce8a81 and 1:2.53.0-20191211.01pre+0cdb5e4.dirty.

The suggested convention keeps the semver package version as "upstream" and the individual package builds as the "Debian version". You can omit the dash or replace it with a different character if you want to remain Debian native (i.e. there is no upstream, and the Debian package version is the authoritative version number).

The details of the Debian version numbering system are documented in the Debian Policy, Section 5.6.12 Version

tripleee
  • 175,061
  • 34
  • 275
  • 318
  • This is all good information for the general case. I'm going to ask some clarifying questions about whether _we_ need to care. So: hashes not ordering lexically; we already have that problem. I don't think we need to bump the epoch, since we went from 1.x to 2.x anyway? We're not building _for_ Debian, just using deb as a convenient container. – Roger Lipscombe Dec 11 '19 at 14:23
  • Simplifying: can we just swap the `-` for `~` -- relegating everything but the semver to "fluff" -- and move on? – Roger Lipscombe Dec 11 '19 at 14:23
  • Yeah, like I said, the epoch doesn't seem strictly necessary here. – tripleee Dec 11 '19 at 14:24
  • The `~` character (tilde) has some specific semantics as well. I suggest you review the Debian Packaging Policy -- I'll update the answer with a link. – tripleee Dec 11 '19 at 14:24
  • Maybe play with these [command-line or programmatic comparison methods for Debian version numbers](https://stackoverflow.com/questions/4957514/how-to-compare-debian-package-versions) – tripleee Dec 11 '19 at 14:29