Re: Multiarch co-installability and binnmus
Hi Wookey,
On Fri, Mar 17, 2017 at 10:44:00PM +0000, Wookey wrote:
> 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:
[...]
> 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?
I don't think waiting to 'just before the release' is a good idea. The issue
can be fixed (by scheduling binNMU's) as soon as it is noticed.
[...]
> 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.
I created a page that gets info from udd (which shouldn't be more than an hour
behind dinstall):
https://udd.debian.org/~ivodd/cgi-bin/multiarch-same.cgi
This page is very basic, and is currently not at a permanent url, but it shows
the current situation in the archive.
> 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.
I made sure that all the pie rebuilds for ma-same packages were done with the
same binnmu number on all architectures, so it's no coincidence that the issue
got better for those.
> 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?
I scheduled binNMU's for most of the packages listed on the page above (they
show 'recent change in wanna-build'). They should disappear from the list as
soon as the binNMU's are in testing.
Some of the packages on the list have FTBFS bugs, or are waiting for other
uploads. I didn't schedule those.
If there are other packages that need a binNMU, let me know.
> If that table of skew is useful we can arrange for it to be
> automatically generated at a permanent URL.
Cheers,
Ivo
Reply to: