Re: binNMU version detection
kbloom@gmail.com wrote:
> How did bin-NMU numbers work for the old numbering scheme on native
> packages?
In a Complicated Way. Essentially, the debian revision and NMU revision were
filled in with 0s (which were, accordingly, not supposed to be used in normal
version numbers).
>What prohibited -3.0.1 numbers from occurring in such uploads before? It
>was just a matter of convention (codified in documentation), no?
Yes. And that's my only real objection here: we've switched to something
undocumented. I think for various reasons the distinction between
binary-only upload version numbers and source upload version numbers ought to
be codified in policy, not just in the developer's reference, but that's
another matter.
> > 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.)
If policy is patched to describe the new binNMU version number format and to
tell people not to use that format for sourceful uploads; and the developer's
reference is patched to match; that would satisfy, oh, *all* my
complaints. :-)
Later, Steve Langasek wrote:
> The primary aim of this change was to address the fact that there was no
> consistent numbering scheme that satisfies the constraint
> binNMU < security NMU < source NMU.
The problems with this were due to security NMUs, weren't they? The old
binNMU numbering scheme makes them consistently and reliably less than
the source NMU numbering.
So the binNMU numbering was changed so as to make it possible for the security
team to name their uploads while guaranteeing that they would sort above
binNMUs and below regular NMUs?
Despite this, the current security team upload naming *doesn't work*. I've
seen "5.8.4-8sarge3" in a recent upload of perl:
$dpkg --compare-versions 5.8.4-8sarge3 gt 5.8.4-8+b1 || echo false
false
So this sorts below the binNMU.
And I've seen "1.3.5-4.sarge.2" in a recent koffice upload:
$dpkg --compare-versions 1.3.5-4.sarge.2 lt 1.3.5-4.1 || echo false
false
And this sorts above the source NMU.
So this change has not yet addressed this problem.
> And contrary to Nathanael's
> protestations, this was discussed publically on debian-devel -- a year ago
> -- and this solution arrived at with the input of an ftpmaster and the
> then-current dpkg maintainer, among others.
Ah. I must have missed that discussion. Pointer?
I would appreciate knowing what was decided on for security uploads, since
it's obviously not being used. Or did you decide to change the version
numbering for regular NMUs instead? If so, that's certainly not being used.
> It just didn't get implemented
> until after wanna-build & co. gained support for binNMUs, making them
> commonplace:
The binNMU version changes could have been implemented long before that by
changing the documentation and announcing to people that the new format
should be used. They weren't. As a matter of fact, this clearly should have
been done before implementing it in wanna-build. It wasn't.
And the security upload version changes -- the original motivation for the
whole thing -- clearly haven't been implemented at all. Even though this
requires only one thing: getting the security team to agree to do it.
It would work, except for native packages, if the security team switched to
using "+sarge?" suffixes. (Well, as long as Debian never picked a code name
starting with "a".) For native packages, it would work as long as binNMUs
and security uploads always added a "0" debian revision number before the +b?
or +sarge? suffix.
Worse, the security team could have made this change well before the binNMU
changes, because it's better than the existing (and common) "5.8.4-8sarge3"
naming. But they didn't.
So, this still seems to me like a really half-assed way to have done things.
Are there plans to straighten this out?
Reply to: