Re: binNMUing on some architectures breaks Multi-arch: same
On Sat, 2012-04-07 at 12:15 +0200, Julian Andres Klode wrote:
> So, a solution would be to add code to your tools to prevent Multi-arch:
> same packages from being binNMUed on a subset of the architectures (or at
> all) and upload sourceful NMUs for the affected packages.
Assuming by "your" here, you mean the Release Team, then it's not that
simple.
There are two ways that binNMUs can be scheduled - either using the "wb"
wrapper tool which (mostly for historical reasons) does live in the
"release-tools" repository or by invoking wanna-build directly.
"wb" is purely a convenience wrapper around wanna-build and has no
concept of packages files (nor should it) so has no means of determining
whether any M-A:Same packages are involved. Conversely, wanna-build
itself can only operate on a single architecture at once so has no idea
whether all or only a subset of arches are having binNMUs scheduled.
It's also worth noting that there are a significant number of people who
can schedule binNMUs other than the Release Team, mostly buildd admins
who may well mass-schedule binNMUs to fix issues on their architecture -
which was, as it happens, the case for the libffi/armhf binNMU - but
also some others.
If the package involved in a selective binNMU needs significant buildd
resources then uploading a full NMU and forcing a rebuild on all
architectures is a waste of those resources. It also doesn't seem
something it would be appropriate for the Release Team to be doing in
order to resolve issues related to e.g. a dependency being broken on a
particular architecture.
I'm not saying that this issue doesn't need resolving, just that "fix
your tools so that doesn't happen" isn't simple, nor necessarily the
correct solution.
Regards,
Adam
Reply to: