Bug#542288: Version numbering: native packages, NMU's, and binary only uploads

[Jonathan Nieder <jrnieder@gmail.com>]

Russ Allbery wrote:

> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -3211,6 +3211,40 @@ Package: libc6
[...]
> +		<var>upstream_version</var> or <var>debian_verison</var>
> +		numbers ending in <tt>+nmu</tt> followed by a number
> +		indicate an NMU.  Either this convention or the convention
> +		above may be used for NMUs of non-native packages, but
> +		NMUs of native packages should use <tt>+nmu</tt>.

Is there any existing practice of using +nmu at the end of the
debian_version (sp) for NMUs of non-native packages?  What is the
advantage of doing so over using the usual .1 convention --- is it to
fit in better with the

	+squeeze1

convention for uploads to stable and testing?

(The .1 convention seems to work better for that, since '.' sorts
after '+' whereas "nmu" sorts before "wheezy".  Though binnmus and
nmus of native packages have the same problem: if I

 1. Upload version 1.
 2. Wheezy is released.
 3. Make an NMU or binnmu in sid, with version number 1+nmu1 or
    similar.
 4. Make a stable update, with version number 1+wheezy1

then the stable update gets a higher version number than the version
from sid.  Another reason not to make native packages, I guess. :))

If I make an NMU that involves repacking the upstream source, should
I consider using a version number like

	1.5.3+nmu1-1

to indicate so?

The rest looks good.

Thanks and hope that helps,
Jonathan