We held a meeting during debconf discussing policy on things which multiarch enables: partial architectures, cross-compilers in the archive, cross-comiled uploads, and a few other things.
I've posted the meeting notes here: http://wiki.debian.org/Multiarch/Debconf11MultiarchRelatedMinutes reproduced here: 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). Agenda for meeting roughly: * keep grub-pc in amd64 ? * partial architectures ? * what to do with gcc-multilib * cross-compilers in archive * cool things to do in the future * stuff that's not arch-independant in contents, but is in there use. (firmware etc.) * How to manage install media 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? It should do 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. Discussion about installing with 3 DVDs until you have all arches you want. How should install media work? Agreement: 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. vorlon: dpkg -l should do the right thing already. Can we drop 32 and 64-bit 'foreign' kernels now? (i.e -amd64 kernel from i386) Kernel team would like to do it now, but may well have to wait one release. (ask kernel team for input) Big picture: How to handle first upgrade to MultiArch ? 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? Subject needs work. 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 native compilers. sledge: ensuring that is a social problem, not a technical one. 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 - i.e apt won't update that package if not available for all arches. 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 by porter NMU, or for devs to upload cross-biult packages. But it wil get a lot easier. Many packages are already 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. Native building finds bugs and is thus useful. (but cross-building also finds bugs). 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. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110731001722.gf5...@dream.aleph1.co.uk
