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

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 
> > scheme for binNMUs, so we can expect to see it for manual binNMUs for a 
> > 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
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
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: