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
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.
Reply to: