* Scott James Remnant ([EMAIL PROTECTED]) [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. 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
