Multiarch cross-architecture meeting minutes

Held at Debconf 11 2011-07-26. 5pm

Present. Approx 12 people, including Steve Langasek(vorlon) (chairing), Wookey (minuting), Mark Hymers(mhy) (FTPmasters), Adam Barratt(adsb) (Release team), Andreas Barth(aba) (Release team), Steve ?McIntyre(sledge) (Install Media team), Mattias Klose(doko) (gcc maintainer), Aurellien Jarno(aurel32) (eglibc maintainer, ports buildd maintainer), Neil Mcgovern(maulkin) (release team), Tollef Fog Heen(mithrandir), Goswin von Brederlow(goswin), Philip Kaluza(pixelpapst) (minuting) + 1 other (sorry, don't know name)

All errors in these notes are Wookey's fault. A lot of people said a lot of things, and getting down the significant points of what was said without missing anything important was not particularly easy, so there are probably a few things missing, and potentially some misrepresentations (although few comments are attributed). please just fix up anything that needs it.

(Philip Kaluza's version of the minutes is also included below).


Firstly: are there any serious blockers (e.g. dpkg) before usingmultiarch in main.

In short, 'No'.

Partial arches?

Use cases:

  1. 'almost complete' e.g amd64, but with 32-bit grub.
  2. 'optimised' (a few packages).

Also ABI-incompatible and optimised: These are not the same, but could probably most easily be treated the same by infrastructure.

Examples of partial arches are:

dak (on the ftpmaster side) doesn't care whether a package set is closed across an arch but britney (release team) does.

Some discussion of when it is useful to have mixed 64/32 arch or not. What packages are pointless in 64-bit form on sparc64, for example. x86_64 is faster than x86_32, but sparc64 is not faster than sparc32 (so no real point making it a full arch).

Build/release people would like to see the definition of an arch being: Arch is something that has to be built on that arch (where arch is a set). This works well for 64/32 or i386+i686.

Archive size: are there major restrictions? ftpmasters: It's already way too big so lets just press on. Biggest churn is in dists. mirror pulse size is more costly than disk size. Are we going to have smaller package files?
Maybe - this depends on implementation.

In a small partial arch we can merge small extra files into host arch package. Is this a good idea? Does apt do the right thing anyway? Needs testing.

likely partial arches: i686, ppc64, sparc64, s390x, mips64, arm/x86 optimisations? ABI-comptible optimisations are not the same as ABI-incompatible. But could be treated the same way.

As well as sparc64 needing base sparc packages, sparc has a sparc64 kernel. So neither arch is complete alone. (but definition of both as needing in both works)

Does allowing partials mean that incentive to move base build of a port forward (eg would we still be using 286) is removed? No, because toolchain support is dropped eventually. We still need to drop old stuff and move base along.

What if you have i386/686/amd64 all on one machine/install. How does install media work? Need to have correct user interface for this. For upgrades as well as installs.

reportbug needs to report the arch of package. Otherwise we have no chance of reproducing bugreports. So does popcon.

Can we drop 32 and 64-bit 'foreign' kernels? (ask kernel team).

That may need release-note update to say 'get this package first', then do dist-upgrade. This always causes some breakage.

How do we decide on arch qualification for release? someone needs to define some criteria. How do we define the set of stuff for percent-built?

Do we want to get rid of anything depending on gcc-multilib?

Doko wants to keep mulitilib capability.

Cross-compilers in the archive

Are we going to upload some. How do we decide which set?

How do we implement cross-builds. From gcc package?

gcc maintainer wants to only have one set of source in archive so cross compilers match.

Use a cross-gcc package. There are two existing methods:

  1. ubuntu gcc-defaults-armel-cross using -source binary packages to do 3-stage build
  2. emdebian 'buildcross' style using cross-dependencies between arches.

The second of these is 'cleaner' but needs inter-arch dependencies. The former is good for bootstrapping and fits in single arch.

why not use cross-arch dependencies? No obvious reasons not to. We already have source package tracking, so this should work.

If we allow explicit cross-arch deps due to partial archs, then it's OK for cross-compilers too.

If cross-gcc package is not per-target arch then it will depend on many arches for the various libc and kernel-header packages. Best to have one package per cross-compiler? Syncronisation issues but also stops breakge in less-used arches affecting more well-used ones.

Is there a problem of out-of syncness breaking things? For multiarch lib versions have to be in-step anyway.

Think about where an RC bug applies. Currently a bug stops package migrating for all arches. Does that still apply for a minor (optimisation) architecture such as i686? Or are they marked 'fucked-architecture'.

Are cross-built things acceptable?

Is a port that uses cross-built packages acceptable?

Officially this is not allowed. But there are already some sort-of exceptions. It's already possible to uploade cross-built be porter NMU. But it wil get a lot easier. many packages are multi-lib built. That's not so different from cross-built in many ways.

You can't run tests (in general). Cross-builds are not trusted to be 'right', but multi-lib builds are.

Decision depends on what the buildds do. It's a per-arch decision. We won't allow random cross-uploads due to convenience.

It would be appropriate for some arches to be entirely cross-built (avr32, win32 perhaps)

Arch:all packages that have to be uploaded from the build arch (and are arch dependent) (e.g firmware)

uploads that have source as well have the binaries thrown away. If only binaries uploaded then binaries are kept.

qemu depends on sparc, i386, mips firmware. This gives you a dependency on 4 other arches. Don't want to add powerpc to apt sources just to install qemu. So should keep them 'all'.

keep status quo is general consensus.

aba: Should we consider how to built them natively?

Installation media - depends on partial arches

Do we have a disc containing multiple arches?

Dong dong dong dong dong dong (Big bell in chruch saying we've been at this for an hour)

Out of time (some people need to go). So let the installer people decide.


Philip Kaluza also took notes. I don't think there is anything very significant that is not above but they are different, and comments are attributed so they are included here too:

vorlon: Agenda for meeting roughly:

vorlon: policy needs to be set first, once implementation is there people will use it.

aba: Ask first, if there are serious blockers (dpkg ?) before using it in main.

vorlon: No.

... (uploading rules)
aba: Only dak needs to be changed.

Sledge: Agenda: What to do for installation media.

TOPIC: partial arches

aba: we have different use cases, should differentiate.

mhy:

Discussion about what packages you'd drop on sparc64 (bash useless ?).

aba: The important part is to have a clear use case for arches that don't have all packages built.

vorlon: Don't spend and hour defining terms, let's talk about policy.

aba: Would expect any port being self-hosting.
vorlon: self-hosting == dependency closure
goswin: not useful definition

vorlon: arch definition for partial arch would include dependency definion on other arch mhy: need experimental verification of theory

...

vorlon: so if it's ok to have partial arch without clear arch dependency, which seems to be consensus, do we need any rules to exclude proposed partarchs ?
mhy: the archive is already too big, might as well keep going. Decision needs to be made on a

discussion about just merging PAckages files for corner cases
consensus is that apt would cope

what partial arches are we actually considering ?
i686, sparc64, s390x, neon, mips64, ppc64, arm(?)

vorlon: What we have heard about partarch concerns, we probably wouldn't treat them all the same.

aba: We have small ports, we have small ports that should grow up (spar64), amd64 is "almost complete" - totally different use cases.

Maulkin: Concern of release team: if we allow for partarches for optimization purposes, we'll end up with _a lot_ of arches, and would still have i286 (or i386) compatibility.
aba: we have toolchain considerations which forces us to throw stuff out eventually.

discussion about installing with 3 DVDs until you have all arches you want.

aurel32: Fix reportbug to report arch of each package, otherwise chaos ensues.
vorlon: dpkg -l should do the right thing already.

Agreement: UI for choosing arches on installation needs to be userfriendly and foolproof.

aba: question: can we remove -amd64 kernel from i386 now, or next release ?
adsb: Better to wait.
kernel team would probably like to do it _now_.
... unclear picture, but maybe better to wait.

Big picture: How to handle first upgrade to MultiArch ? => Releasenote it ? Do we break systems for non-

vorlon: Arch qualification for release ? adsb: Need to follow up later. very hard stuff...

TOPIC: cross compiles in the archive ? Q for ftp master ? Also for release team. aba: We found bugs by compiling natively, was good. goswin: The question is first, do we allow cross-arch build-deps ? vorlon: Building with a cross compiler needs different arches enabled. mhy: Pragmatic suggestion: start with cross-build on amd64.

doko(?): should build cross compilers from same gcc package eventually. Wookie: Either we allow cross-arch build-deps, or if we don't, we need to fuzz around with source packages. goswin: Built-using ? pixelpapst: (not applicable IMHO)

vorlon: doko, it's not your problem to keep the cross-compiler source sane, it's problem of cross maintainer doko: but all compilers should be built with the same set of patches, oterwise ppl will build there own compilers sledge: slap them, tell them not to do that, it's a social problem

discussion about out-of-sync packages vorlon: out-of-syncness does cause apt to not install / update that (build-dep) package ...

TOPIC: using cross-compilers on a port autobuilder, would anybody veto that ?

Maulkin: Currently policy says we don't allow that, but that's also a lie. aurel32: it's possible for packagers to upload x-built packages anyhow. Maulkin: Release team policy is that things should be natively compiled, this policy still stands as of yesterday night. mhy: Then r-t policy should be respected, with exceptions for individual (starting) architecture.

TOPIC: arch:all packages that are not arch:all (firmware etc.) mhy: annotating arch:all packgakes if they need to build on specific arch ? vorlon: brings its own problems mhy: somewhat corner-case

...

sledge: TOPIC: do we end up producing CDs for each arch combination ? vorlon: consensus seems to be to be to delegate to d-i and CD team, let them make that decision