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

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

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.



Reply to: