Bug#842459: nmu: zlib_1:1.2.8.dfsg-2
On Sun, Oct 30, 2016 at 11:47:35PM +0100, Emilio Pozuelo Monfort wrote:
> To clarify: if this one package is blocking your cross-build efforts (which I
> appreciate), I can do it. I don't want to end up doing this, then those two
> other packages, then some more stuff... Instead, this should be fixed in the
> right place.
I hesitated quite a bit before filing this nmu request, precisely
because I know that it means busywork for you. These skews are kinda
frequent and mostly come and go away. Just zlib is special here in that
it has a low upload frequency combined with a high impact (1/4 of the
I do agree that a better solution should be found. I just don't see any
good solutions that could be applied. There are basically two
* Whenever you nmu a Multi-Arch: same package, nmu it for all
architectures. This obviously wastes buildd resources somewhat, but
we know that it works. The nmu tooling would need better support for
automatically handling this correctly in all cases.
* Teach dpkg to coinstall different binNMU versions. I know that
Guillem Jover has been slowly working towards this (e.g. by trying to
turn packaging more declarative), but there are more problems outside
the scope of dpkg. Multi-Arch: same requires that shared files must
have exactly matching content. If one rebuilds a package with
differently versioned dependencies, we risk content changes in shared
files. This is not a theoretical issue (e.g. formerly libxdmcp). So
even if dpkg supported this mode, we'd get binNMUs that are broken
from a Multi-Arch perspective and would have to nmu them again.
nmuing just zlib has a significant impact on cross build qa. I do not
see nmuing Multi-Arch skews as a frequent operation. Towards the end of
the freeze we should consider nmuing all remaining skews in one block.
The reproducible builds folks likely also want nmus, so maybe we can
So do you think this request is reasonable now? Either way, let's not
discuss it further. Either nmu or not and close this bug.