• Status: draft


There is currently a problem, at least in Debian, where we have arch:all packages that contain architecture specific objects, which require a specific host architecture to be built for, that are used not only on the host architectures but on foreign ones as data objects for things like emulators. This is really a packaging anomaly.

The main reason for this anomaly is two fold. First we cannot yet make use of cross-architecture dependencies, as several parts of the project do not support them. And second, having to add almost every supported architecture as foreign architectures to both dpkg and apt, to be able to satisfy those cross-architecture dependencies and be able to fully use something like qemu would be untenable.

Besides the conceptual problem of subverting the architecture system by introducing arch-independent packages containing arch-specific files, this has also a practical problem. These packages cannot be built on any random system, as in many cases they depend on arch-specific toolchains and packages.

The problem and affected architectures can probably be split in two sets, one of architectures for which there is a pre-existing non-freestanding architecture with packages such as vgabios, seabios, sgabios, bochsbios, proll, openhackware openbios, memtest86, mbr, grub, syslinux, linux, kfeeebsd, gnumach, etc. And another set with architectures for embedded or peripheral/secondary CPUs, such as ath9k firmware, PIC controllers, etc.


There are currently some workarounds being used or proposed to solve part of those problems, but they are still partial solutions.

The first workaround was introduced by AurelienJarno. It consists on building a freestanding toolchain as part of the package build process. This solves the problem of the buildability of the packages, but not the conceptual issue with the arch:all usage. This one is nice, because it makes the build truly independent, and requires no infrastructure changes.

The second workaround is to defined a new field (current proposals favor Build-Indep-Architecture) and use that to declare the actual host architecture this packages should build code for, even though it's still an arch:all package. This also only solves the buildability isssue.


A solution that would, ideally, solve all of the above problems would be to create a new set of freestanding architectures, which would be kernel-independent, with a form like none-<cpu>, such as none-i386, none-sparc and similar.

These new architectures would only contain packages for things that are only dependent on the <cpu>, such as firmwares, boot loaders, kernels and similar. And as such would be very lean and would not incur major downloading nor resolver computational costs, even if all of them would be enabled on a given system.

Ideally (although practically difficult) the package manager would accept by default freestanding architectures as native for the ones matching the <cpu> of the current native architecture. This could be implemented initially by hardcoding the mapping and/or enabling the architectures by some package in the system at upgrade/installation time.

They would either require a new set of freestanding compilers, or they could simply expect packages building for those architectures, to use a compiler flag equivalent to gcc's -ffreestanding.

When it comes to maintainer scripts, they could depend implicitly on the packages from the Essential:yes set, or explicitly on anything that has been marked as Multi-Arch:foreign.

These new architectures would need to be handled specially when setting up a build daemon, as they would not be self-contained (they would be missing a libc!), so they would need to be deployed on a matching full architecture. In the end they might end up being similar to setup as an arch:all buildd.

This would still require to fix our infrastructure to support cross-architecture dependencies (at least dak, britney and wanna-build?). But all other concerns should pretty much disappear with this proposal.


Thanks to JessicaClarke, Helmut Grohne for helping hammer down some of the details of the initial draft proposal.