Experimental Physics and
Industrial Control System

thanks for the reflection! When putting the entire idea together, the aim was to: honor the existing practice (to a reasonable degree), honor the general practice, and keep the process practical (meaning git-buildpackage and all its invocation working straightforwardly). That suggests or cuts out certain ideas; say, if we decided to use <upstream>-<revision> for native packages, git-buildpackage would fail right away (e.g. epics-debhelper 8.16-1 wouldn't build).

1. Actually, in our old repository setup, there are package versions like "8.16+zjessie+nmu1". You can see the combination of "forking" and NMU concepts here, and upgrades are handled in an interesting manner. While comparison-wise squeeze < wheezy, wheezy > jessie - so "z" is added to make wheezy < zjessie. It would continue for stretch, e.g. zjessie < zstretch... As suggested in the document you mentioned, handling "forking" with the debXuY format would introduce a reusable ordering and that I picked up to replace "zjessie".

2. While the document covers native and not-native cases without "forking", it doesn't explicitly state what to do in either case -with- "forking". It is true that debXuY supersedes nmuX when taken in that context; given #1 where debXuY is a better option for simply specifying the distribution for which the package is built, putting both serve different purposes. I concur however that native and not-native cases can be distinguished by the preceding version format, 8.16+deb8u4 is native while 5.5-1+deb8u1 is not because of the hyphen. So using both additions is indeed excessive.

For NMUs in general, I have actually considered our internal build uploads to be "NMUs" regardless of the uploader being a maintainer or not. That is, Debian revision comes from epicsdeb and everything on top of that (like the upload number) is "non-maintainer". Otherwise the versioning which we expose would be different based on who uploaded the package to build based on their maintainer status.

I found an extensive discussion on a Debian mailing list, related to the topic, here. In particular, the case which I would like to cover with +nmuX is "recompilation or binary only NMU (common use case: outdated build environment, no source changes)". Digging through how "policy should document the +bN standard for binNMUs" and "allow +nmu to be used for non-native packages as well", I concluded for myself that we'd better somehow generalize to a simple case which suits needs earlier mentioned to differentiate packages.