Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Tue, 18 Aug 2009, Manoj Srivastava wrote:
> Additionally,
> § 5.6.21. `Files' mentions that the .dsc will contain a diff.gz if
> applicable
> § C.1.1. `dpkg-source' states that it creates a diff.gz if
> appropriate, and looks at the diff.gz while extracting if
> applicable.
Heh, reading this remind me that policy should probably be updated to
reflect the new source package formats... (diff.gz can also be
debian.tar.<ext>, etc.)
> Given these, I read this as letting the tools rely on
> the following invariants, even though these are not explicitly spelled
> out in so many words in policy:
>
> 1) If there is a - in the version number, then the package is
> non-native
> a) the upstream version is the part of the string until the last
> '-' in the version number
> b) there is a .orig.tar.gz and
> c) diff.gz referenced in the .dsc
> 2) If there is no '-' in the version number, then the package is a
> debian native package
> a) there is no debian revision, all the version number is the
> upstream version number
> b) there is a tar.gz and no diff.gz in the .dsc file
There's no such invariant although it's a recommended practice:
http://lintian.debian.org/tags/native-package-with-dash-version.html
And the type of file associated is going to be different once the archive
accepts new source formats.
Format: 1.0 accepts either .tar.gz or (.diff.gz + orig.tar.gz)
Format: 3.0 (native) allows .tar.{gz,bz2,lzma}.
Format: 3.0 (quilt) allows debian.tar.{gz,bz2,lzma} +
orig.tar.{gz,bz2,lzma} + optionals orig-<foo>.tar.{gz,bz2,lzma}
dpkg-source doesn't impose any restriction on the package's version
when using any of those formats.
> 1) dch --nmu adds +nmu1 for native packages
> 2) +nmuX is already supported by devscripts and lintian.
> 3) the developers reference also advocates adding +<codename>\d+. It
> also advocates using exactly the same tar.gz file as already in the
> archive.
While I would like us to standardize on +nmuX for all NMU, there's no general
consensus here. The developers-reference has changed again the recommendation
to match the dch --nmu practice:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532945
Now I believe that consistency here would be a win that is more important
than the ugliness or aesthetic problem that some DD seem to have with this
convention. I don't know if the discussion during the policy process can
lead to agreement on this.
> I propose that we carve out a version number space that reserves
> a suffix match of
> \+nmu\d+$
> for packages that are NMU's, and make this invariant for native and
> non-native packages.
>
> 1.0.1 --> 1.0.1+nmu1
> 1.0-1 --> 1.0-1+nmu1
And NMU of a new upstream version is 2.0-0+nmu1.
> Similarly, for a recompilation or binary only NMU (common use
> case: outdated build environment, no source changes), the suffix can be
> \+b\d+$.
> This does require and modification of the changelog, so that the
> version number is changed (and thus the new package is used to upgrade
> the older, broken package).
This suffix is enshrined in the dpkg tools because it knows to strip it
to generate the source:Version substvars. So it's definitely something
that can be standardized by the policy.
> A corresponding name space can be carved out for security
> uploads. Obviously a solution would be to add +debion>.<counter>, where
> <version> should be anything that sorts correctly, such as the current
> stable version with something added if the upload is to testing.
> \+deb\d\d.\d+
> \+debt\d\d.\d+ (testing only, sorts ahead of stable)
>
> where
> 1.0.1 --old--> 1.0.1+etch1 --> 1.0.1+deb40
> 1.0-1 --old--> 1.0.1+etch1 --> 1.0-1+deb40
>
> (sarge --> deb31, etch -->deb40, lenny --> deb50)
We had this discussion in the threads that discussed DEP1 on -project.
We did not reach a consensus (with the security team) here.
Subthread starting here:
http://lists.debian.org/debian-project/2008/08/msg00136.html
(Thijs is part of the security team)
But I also think that it would be nice to have a working long-term
solution and I would be in favor of such a scheme. The main objection was
that we do not know the next version in advance and the release team
has changed this fact, we already know that squeeze will be 6.0 and it
should stay the same in the future as the reasoning of this was to
facilitate the work of documentation writers.
> In this case, binary only uploads sort below security uploads,
> but NMU's sort above security uploads.
>
> This solves the use case:
> - The package version is 1.3 in all distributions.
> - A security issue is found.
> - 1.3+deb50 is uploaded to stable and testing.
> - The maintainer isn't available, and 1.3+nmu1 is uploaded to unstable.
> - Some time passes, and the package is about to migrate to testing.
> - Migration works, because 1.3+nmu1 >> 1.3+deb50.
>
> Using just code names is bad becase there is no ordering:
> a) 1.0-1sarge1 >> 1.0-1etch1.
> b) 1.0-1etch1 << 1.0-1lenny1
Indeed.
> You can base security uploads on NMUs, so I think you could get
> +deb50.1
> +deb50.1+nmu1
> +deb50.2
> +deb50.2+nmu1
Hum I understand +nmu1+deb50.1 for a security upload of a package whose
last upload was an NMU, but I don't see in what occasions you would NMU a
package in stable/testing (package in unstable don't have security
uploads). And even if you did, I don't see why you keep the +deb50.1
instead of simply replacing it with +nmu1.
Cheers,
--
Raphaël Hertzog
Reply to: