Bin-NMUs break multiarch co-installability, so we always end up with a somewhat random set of packages+architectures in a release which would be co-installable, except that some arches got binNMUed so they aren't. I would like to discuss with the release team what we can do to minimise this breakage, and when to do it. To clarify the issue, for anyone unfamiliar: You can only co-install packages of the exact same version, built from the same source, (because otherwise you can't assume the files are the same across architectures). A binNMU changes the version (and may have changed the contents) so you can't co-install foo_1.2-3:arch1 and foo_1.2-3+b1:arch2 even though it would in practice probably work fine. In theory this could be fixed by dpkg being more lenient and deciding that foo_1.2-3 and foo_1.2-3+b1 were equivalent for MA-purposes, but the dpkg maintainer does not want to implement this, and allowing such an exception in apt and aptitude and other tools would be problematic (at best) too: https://lists.debian.org/debian-devel/2017/01/msg00004.html So at least for Stretch, and probably for the foreseeable, either the versions match exactly or things are not co-installable. There isn't much point doing MA 'unskewing' builds, if there is going to be another upload of a package anyway, or further binNMUs, so it's best if any unskewing is done as late as possible before release. Ideally, just before release, we would go and just rebuild every package that emits an MA:same binary package and has a binNMU for some arch or other. That would eliminate the issue completely, but it's probably also quite a lot of building and delay. What does the release team think of this idea? Is there a good time to do such a thing? In practice the real harm comes from libraries that are 'low' in the dependency tree, so just unskewing those removes a very large fraction of the harm. What does the rlease team think of doing that? If one restricts cross-building to chroots, then that reduces the set of packages that really must be co-installable still further as you don't have too much BUILD arch stuff installed, so clashes are less likely. The set of things that cause breakage even in this case _really_ needs to be fixed to make cross-building work in debian stretch. Is the release team happy that we at least try to ensure this set of packages is multiarch-syned? (Identifying the set will need some more work). Josch produced a chart of the current set of multiarch-skewed MA:same packages: https://mister-muffin.de/p/Rfbk.html So that's 130 packages right now, but only a fairly small number of those are really important for co-installability. It seems that after ivodd did a lot of rebuilding for pie fixes, most of the packages that really matter got fixed, but it would be good to do at least some of that list, and most importantly, check that the situation doesn't get significantly worse before release with any vital low-level packages being affected. So, I'd be very pleased to get some advice from the RT on how best to deal with this, without getting in their way, but maximising the co-installability of what ends up getting released, and if there is a good time to do some unskewing? If that table of skew is useful we can arrange for it to be automatically generated at a permanent URL. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: Digital signature