Re: binary NMUs and version numbers
* Scott James Remnant (email@example.com) [041128 12:55]:
> To summarise the discussion so far:
Thanks for your nice summarising.
> - 1.2-3.0.1 (bin-NMU of source), 1.2-3.2.1 (bin-NMU of NMU).
> Current style; this clashes with many valid version numbers,
> especially when used for native packages. It does not pass (c).
> - 1.2-3b1
> "Build #n" style; slight potential clash with valid version numbers,
> but not a major one. Passes (c) if the string matches [^ab].
AFAICS, it is already consensus that neither of these formats is the
ways to go.
> - 1.2-3+b1
> "Plus build #n" style; this clearly identifies the fact that it's a
> bin-NMU in all situations. It does not pass (c), however we can
> alter the security and cdd upload format to +sec-woody1 (or any other
> string matching +[^ab]).
> - 1.2-3^1
> "Build epoch" style; this would require changes to dpkg and APT's
> versioning scheme, requiring a skipped-release use delay. ^ would
> sort less than everything, including letters, so passes all 3.
> My personal feeling currently gravitates towards the +b1 form, with
> +sec-woody1 and +patch-ubuntu1 as possible security and cdd forms; I
> don't think we have enough time to get the build epoch style into all
> the required software and tested before sarge.
I guess we have enough time for even doing the build epoch right before
release of sarge. And, frankly speaking, I think we should first do the
right decision, based on the technical facts, and than consider how we
can implement the best solution.
My personal feeling is different to yours: I prefer the build epoch
solution, because I consider it the cleaner solution, even if it
requires changes to some packages. However, even if you disagree and go
to the +b-solution, I would prefer that much to the current one, and so
I hope that we are able to finalize the decision soon.
Thanks for your effor.
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C