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