Where did the rest of this discussion come from? I can't find it here on debian-devel, but I assume it has something to the patch that I posted to debian-devel, and later to debian-dpkg at http://lists.debian.org/debian-dpkg/2006/01/msg00045.html
Nathanael Nerode wrote: > Steve Langasek wrote: > >>>Which would be totally pointless until dpkg itself is fixed to give >>>packagers an alternative to ${Source-Version}. >> > Thomas Bushnell BSG wrote: > >>I thought we had a fix-strategy in place for addressing these cases. >>I'm sorry if we don't; then of course this strategy doesn't work. :( > > > I *wrote* one, but then they went and changed the binNMU version numbering. > > This *cannot* be done without a consistent numbering scheme for binNMUs which > we can rely on. Given that the numbering scheme was changed silently at a > random time for no apparent reason, I don't know if I can rely on this > numbering scheme being retained. You put way too much premium on the idea that some detail this small should be permenant. It's a very simple patch that can easily be changed if necessary, and a dpkg-dev change can easily be synchronized with a bin-NMU change. > It appears that nothing prohibits a "b????" suffix in a regular source NMU, > or > indeed in a regular maintainer upload, for native packages or non-native > packages, so I believe binNMUs can be automatically detected any more. What prohibited -3.0.1 numbers from occurring in such uploads before? It was just a matter of convention (codified in documentation), no? If your package is using +bN numbers for something else, you can continue to use the old Source-Version variable which has not changed, and things will work no worse than they did before. > There's also no documentation of this numbering scheme: does it differ when > applied to a {native, non-native} package? A {maintainer upload, NMU}? > So actually I can't write a fix, period. How did bin-NMU numbers work for the old numbering scheme on native packages? > Furthermore (sigh) the developer's reference still advises the old numbering > scheme for binNMUs, so we can expect to see it for manual binNMUs for a good > while yet. So any routine will have to handle *both*. Let's patch that and solve that problem. (I'll try to do that within the next couple days, although I should probably be overruled by someone who knows a little bit more about it than I do.) > So the silent and unmotivated changes made to binNMU version numbering have > *prevented* this from being fixed. Good example of how not to do things. After pursuing some of the previous posts on the issue before posting my patch, I discovered that there was concern that it would be more difficult to write the proper patch for the old binNMU format, specifically knowing to convert -3.0.1 to -3 but -3.1.1 to -3.1, and other things like -3.sarge1.1 or somesuch. It was my impression that this change to +b1 numbers was designed to make this patch easier to implement. Of course, I wasn't involved in any of the discussions, so I don't know for sure. > I await advice on how to fix this problem now that we are stuck with this > random, unmotivated, undocumented, likely-to-break-things change. Oh, and > I'd like the head of whoever changed it while I'm at it. :-) Yes, it would have been nice to have been told. Actually, we were told on debain-devel-announce. Writing patches is not hard. I'm not complaining. If a change comes along, we'll write a new patch. What's to worry about? --Ken Bloom -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]