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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
