Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Thu, 01 Apr 2021 at 18:17:59 -0700, Russ Allbery wrote:
> +- ``upstream_version`` components in native packages or
> + ``debian_revision`` components in non-native packages ending in
> + ``~debNuX`` also indicate a stable update, but of a different type.
> + This version convention indicates that the stable version of the package
> + was updated to a new upstream release, as distinct from the ``+debNuX``
> + convention that indicates additional changes were applied to the
> + existing stable release. ``N`` and ``X`` mean the same as with
> + ``+debNuX``.
I don't think this is quite it.
For me, ~debNu1 implies that a stable update was made by taking a newer
Debian package (typically from unstable) - not necessarily a new upstream
release! - and backporting it in its entirety, mechanically equivalent to
a ~bpo version but released to all users of stable rather than just those
who have opted-in to backports.
src:pango1.0 in Debian 10 is an example of this: we fixed CVE-2019-1010238
in testing/unstable by applying a patch (1.42.4-6 was vulnerable,
1.42.4-7 was fixed). We could have continued by fixing CVE-2019-1010238
in stable as 1.42.4-6+deb10u1, but the result would have been functionally
equivalent to 1.42.4-7, so it seemed clearer to just take 1.42.4-7 and
rebuild it for Debian 10 as 1.42.4-7~deb10u1. We later repeated the
process for 1.42.4-8 with some non-security fixes.
If the stable version of the package was updated to a new upstream release
instead, there are two ways that can happen. One way is to take the version
from testing/unstable and rebuild it in stable, like src:openjdk-11 in
Debian 10: 11.0.9.1+1-1 was uploaded to unstable first, then rebuilt
in Debian 10 as 11.0.9.1+1-1~deb10u1.
The other way is to repackage the new upstream release from first
principles, either because it's a new release from an upstream branch
that's older than the one in testing/unstable (like src:flatpak in Debian
10), or because testing/unstable already has packaging changes that aren't
suitable for stable (like src:dbus in Debian 10). In this case it would be
misleading to use a version number like flatpak_1.2.5-1~deb10u1 (because
1.2.5-1 never existed) or dbus_1.12.20-1~deb10u1 (because 1.12.20-1 did
exist, but the version of dbus in stable was not based on it, and does
not have the downstream changes from that version). Instead, the convention
that has emerged is to use 0+deb10u1, by analogy with the convention that
an NMU introducing a new upstream release has revision number 0.1.
~debNuX for X > 1 indicates subsequent stable-specific changes applied
on top of to a ~debNu1 version.
(Sorry, I'm not sure how to express all this in a paragraph or two...)
smcv
Reply to: