Bug#542288: Version numbering: native packages, NMU's, and binary only uploads
Jonathan Nieder <jrnieder@gmail.com> writes:
> 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
Consistency. Why have two different version numbering conventions for
NMUs? The .1 convention cannot be used for native packages, so we have to
have another, and once we have another, why not use it for both?
Although possibly that answer is the sorting issues you identify, while
we're still using code names for stable updates, so maybe I should just
take that out since it isn't widely used right now.
> --- is it to fit in better with the
> +squeeze1
> convention for uploads to stable and testing?
This should really be changed to use something else that involves the
version number of Debian rather than the code name, but there doesn't seem
to be consensus on this yet and the security updates are all still using
+codename (which is about to get more problematic since I doubt the next
codename will sort alphabetically after wheezy).
> (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. :))
Yes, this problem exists already and one has to work around it by being
careful with the versioning of stable package uploads. We get bitten by
this from time to time.
> 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?
No, I've never seen anyone do this, and there are good reasons not to (the
maintainer should be able to use the repackaging without keeping nmu in
the version). I'd use the same convention as normal: 1.5.3+dfsg1-0.1 or
1.5.3+dfsg1-0+nmu1.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: