[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: binNMU version detection

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

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

> 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.

Reply to: