Next steps with multiarch in Ubuntu

Work items:
flush ppa:vorlon/multiarch to the oneiric archive: DONE
[vorlon] push multiarch patches from natty to Debian: DONE
[vorlon] propose a vendor neutral interface for querying the current multiarch directory path: TODO
[cjwatson] Look into ensuring that amd64 images have i386 Packages files once multiarch is turned on for amd64: DONE
[mvo] talk to andrea (from debdelta fame) about improved pdiff as a tree: TODO
look at pdiff for translations: TODO
[cjwatson] consider removing long descriptions from the Packages file and move them into the Translations-en file instead (apt supports that now): DONE
[scottritchie] migrate everything he added to ia32-libs to multiarch (maybe and then some): POSTPONED
evaluate publishing all i386 packages into a shared amd64+i386 packages file for multiarch (decided against due to inflexibility): DONE
[vorlon] check that upgrades from lucid give a reasonable experience via update-manager with detached translations: TODO
[cjwatson] Enable multiarch by default on amd64: DONE

Notes:
Multiarch landed! Party time!
Things to consider:
 - getting rid of ia32-libs completely, in favor of multiarch
 - exposing i386 packages on amd64 by default
 - cross-building of packages
 - socializing with upstreams! (non-gcc compiler support?)
 - maybe we should make default CD on ubuntu.com 64-bit
Next steps:
Current status:
- With the help of Steve's PPA, flashplugin runs out of i386, and not out of ia32-libs
- Still have to setup apt by hand
- no multiarch on any systems by default
- -dev packages, what breaks

Oneiric goals:
- ia32-libs out of the archive (i.e. multiarch-ify everything in ia32-libs - at least 200 libraries)
- Get rid of lib{32,64}foo

Shipping multiarch in Debian
  http://wiki.debian.org/Multiarch/Bootstrapping
 - Working eglibc is in unstable, should land in testing soon
 - Next is uploading multiarch-support
 - gcc-4.4, -4.6 uploads (-4.4 is default on sparc, ia64)

Debian's dpkg doesn't support multiarch fully yet, but can start moving libraries around after toolchain changes land
Can start pushing up Ubuntu patches once bootstrapping todo finished

Packaging recipes for conversion: http://wiki.debian.org/Multiarch/Implementation

Needed: recipes for how upstreams should handle multiarch setups
 (mostly amounts to "don't do library lookups yourself")
 But also want non-Debian-specific ways for toolchains like gcc to discover multiarch prefixes and triplets (autoconf?)
    equivalent of dpkg-architecture -qDEB_HOST_MULTIARCH

One linker which we can patch (binutils), lots of compilers, all of the compilers need to know about multiarch

Some libraries have headers which are arch-dependent. Could split out arch-any/arch-all headers, but generally easier to move all headers to multiarch prefix

= Exposing i386 packages on amd64 by default =

Today: make change in config, download Packages for all arches
Increase download time for downloading extra Package files
(If we enable, need to do it on upgrade, too)
There is a syntax - "deb [amd64,i386] http://...", though if you do that without also making apt.conf change, you get Packages files but can't install them

Could we leave it turned off until you need it?
Might not be able to tell you need multiarch until you actually look there.
software-center has that information for the main archive
Want to keep arches separate for things like partial mirroring

What about having a subset of packages available for multiarch in the packages file?
debdelta guy had an idea to make pdiff more useful:
 - instead of having linear pdiffs, have diffs by powers of 2 (i.e. diff between current and current-2, -4, -8, etc.), then do binary search for pdiff you want
 Would require work in soyuz, apt, Debian

Can we change apt to by default only look at foreign arch packages that aren't available in the native arch?

Could we have a single multiarch-friendly Packages file, effectively cat'ing together all of the arches

Debian main
 - binary-i386 Packages.gz: 9.5M
 - all arches combined, sorted, gzip -9'd: 38M (14 arches, includes ones not planned to be shipped in wheezy but whatever)
 - about 4x
 - use Translations-en or similar for long descriptions

25% overhead for just Ubuntu, universe, i386+amd64

Do we want to just create this single Packages file?
We could also remove long descriptions, since they're already localized

What about multiple runtimes installed side-by-side?
 - No current design (design only covers libraries)