Re: binNMUs: please exercise some care

On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:

> >> Ah, cool – so we have only to patch this tool to automatically
> >> use the highest number per batch on all affected architectures
> >> (or even to use the highest number if all architectures would
> >> be touched, but that’s probably an unreasonable amount of code
> >> change).
> > 
> > Sorry, aren't you saying the same thing in both cases? If not, can you rephrase
> > or expand that?

> This won't help when we have to schedule a binNMU on one or two architectures
> and not all of them.

That’s why I made the distinction. The change to the tool can be done
by taking the highest version number across the _listed_ or _all_
architectures. (The listed ones is probably better.)


On Fri, 23 Oct 2015, Adam D. Barratt wrote:

> Well, except you only really want to do it for libraries that are ma:same, as
> that's the only case where it actually matters and otherwise you're
> pointlessly losing versions.

Right, but it’s not as if losing versions would have any bad impact.

> It's also not quite that simple, even working things out by hand - see #599128
> for example.

Hm, I’m still under the impression that the +bN suffix to the Debian
version of the package in the archive is the authoritative source for
what binNMU version a package currently has, as that’s taking porter
uploads into account which is a requirement. If the current code
doesn’t do that I consider it a bug which must be fixed (at the same
time, or before doing this change), which makes it more tricky, yes.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg