(replying to the list, not sure why Reply-To: was set)
On 6 November 2011 03:15, Steve Rae email@example.com wrote:
I understand the release tag numbering in spec files (for ‘rpm’ packages): Release: <CI_CNT>.<B_CNT>
What does CI_CNT and B_CNT stand for? I could guess Continous Integration Count and Build Count.
Without understanding how they work *exactly*, I agree it is useful to get a new release number every time you build the software. The resulting package and the code it contains might differ, that's why a rebuild happens after all.
However, I am unable to determine how to perform the same “release” numbering in ‘deb’ packages.
-- actually, it seems to use the <version>-<release> as specified on the first line of the ‘debian/changelog’ file (in debian.tar.gz)
I think this works as designed. Debian policy does not know the concept of numbering builds. The least significant part of the version is the Debian revison, in other words a version number for the Debian specific packaging.
I believe the top entry of the changelog must match the version of the package (although I couldn't right now find the place in the policy where this is required. Would need to try lintian, to see what it says it's not the case)
So to my understanding build numbering would first needed to be added to the Debian policy before you can make it work in a consistent way. I'm not actively following Debian policy discussions, not sure whether it has ever been discussed. One downside is of course that such build numbers make only sense within one consistent build system. If you compare build numbers assgined by two different systems you can't really tell anything. Even equal would not mean equal. I could imagine that not everybody would welcome such "unreliable" info in your packacking system.
There is actually a discussion about amending Debian version numbering ongoing just these days. http://lists.debian.org/debian-policy/2011/10/msg00036.html (followup also in November) However, it looks like a bit different topic to me.