Differences between revisions 4 and 5
Revision 4 as of 2011-07-29 16:58:41
Size: 6611
Editor: wookey
Comment:
Revision 5 as of 2011-07-30 09:07:59
Size: 6668
Editor: MarkHymers
Comment:
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
1) 'almost complete' e.g amd64, but with 32-bit grub.
2) 'optimised' (a few packages).
 1. 'almost complete' e.g amd64, but with 32-bit grub.
 1. 'optimised' (a few packages).
Line 28: Line 28:
Dak (ftpmaster team) doesn't care whether package set is closed across arch.
B
ritney (release team) does.
dak (on the ftpmaster side) doesn't care whether a package set is closed across an arch but britney (release team) does.
Line 32: Line 31:
x86_64 is faster than x86_32, but sparc 64 is not faster than sparc 32 (so no real point making it a full arch). x86_64 is faster than x86_32, but sparc64 is not faster than sparc32 (so no real point making it a full arch).
Line 43: Line 42:
likely partial arches: i686, ppc64, sparec64, s380x, mips64, arm/x86 optimisations? likely partial arches: i686, ppc64, sparc64, s390x, mips64, arm/x86 optimisations?
Line 52: Line 51:
Reportbug needs to report arch of package. Otherwise we have no change to reproduce bugreports. So does popcon. reportbug needs to report the arch of package. Otherwise we have no chance of reproducing bugreports. So does popcon.
Line 73: Line 72:
Use a cross-gcc package. There are two existing methods: a)ubuntu gcc-defaults-armel-cross using -source binary packages to do 3-stage build. b) emdebian 'buildcross' style using cross-dependencies between arches. b is 'cleaner' but needs inter-arch dependencies. a) is good for bootstrapping and fits in single arch. Use a cross-gcc package. There are two existing methods:

 a.
ubuntu gcc-defaults-armel-cross using -source binary packages to do 3-stage build
 a.
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.
Line 102: Line 106:
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'. 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'.
Line 106: Line 110:
Aba: Should consider how to built them natively? aba: Should we consider how to built them natively?

Multiarch cross-architecture meeting minutes

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

Present. Approx 12 people, including Steve Lanagsek (chairing), Wookey (minuting), Mark Hymers (FTPmasters), Adam Barratt (Release team), Andreas Barth (Release team), Steve ?McIntyre (Install Media team), Mattias Klose (gcc maintainer), Aurellien Jarno (eglibc maintainer, ports buildd maintainer), Neil Mcgovern (release team), Tollef Fog Heen, Goswin von Brederlow, Philip Kaluza + 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.


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:

  • sparc64 and ppc64: could expand to full arch, win32 won't. (this is a relatively exotic 'future' possibility

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.