binary NMUs and version numbers

[Andreas Barth <aba@not.so.argh.org>]

Hi,

there has been some casual discussion on IRC about version numbers for
binary-only NMUs, and different ideas have been exchanged. I try to
summarize the status, so that we can get to a decision.

Our current strategy is to add as third component a binary-only number,
e.g. the first binary-only NMU for 1.2-3 is 1.2-3.0.1 (the .0) marks the
"no real nmu".  There are three issues with that strategy that I know of:
- Britney gets confused if a package with a version like 1.2-3.sarge.0 and
  1.2-3.sarge.1 is uploaded.
- 1.2-3.0.1 is greater than 1.2-3woody.1 (which is our usual security NMU way),
  so that there is a rejection of the security fix on only that architecture
  by the main archive (but not by security.d.o).
- In that binary package, the source version is used as 1.2-3.0.1 which is not
  really true (at least, no source with that version exists in the
  archive). So, katie needs to do special handling there.

The last issue could be solved with any handling, even with the current
one, so I will ignore it in the rest of this mail.


One idea was to use for binary-only NMU as 1.2-3b1. This has the advantage
that current dpkg can handle it, and also that britney doesn't get confused
any more. However, it doesn't solve the second issue.


The other idea is to use a "binary epoch" for binary-only NMUs, i.e.
1.2-3^1 for the second set (with the implicity epoch of 0 if none is
given), and a new sorting rule that 1.2-3^1 >> 1.2-3, but smaller than any
other suffix (and of course, ^ just stands "for a new character"). The
advantage is that this solution is the nicest one from the theoretical
point of view. It solves both problems with britney and the security
uploads, but the disadvantage is that we need to teach dpkg first how to
handle that new character before we can use it. So, we probably should fix
that in sarge, so that we can use the new character in etch than.


I personally would like the binary epoch most, but of course it is not my
call to decide in the end. Comments are appreciated.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C