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

Multiarch co-installability and binnmus

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:

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:

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.

Principal hats:  Linaro, Debian, Wookware, ARM

Attachment: signature.asc
Description: Digital signature

Reply to: