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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
