These are ideas that may be interesting to Emdebian or Debian as a whole. If you have anything to add to them, feel free to do so. Note that Debian Policy is not a reason not to do anything; it is a reason to think about a transition plan.

Having cross-only architectures

The general idea is that the architectures we mainly see as "targets" would be promoted to full Debian architectures as far as the packaging tools are concerned. These architectures would probably not have an installer or own autobuilders; instead, a subset of the archive would be cross-autobuilt for them.

This would allow us to get rid of any header files for another architecture (such as the mingw32 or PalmOS stuff) inside the Debian archive (thus shrinking it) and confine them to the relevant architecture only; at the same time packages that do not build cross binaries by default (only very few of them are even capable of that, wxWidgets for example) could be more easily ported to these architectures, as you no longer need to add control stanzas for the cross-compiled packages -- the different architecture is enough to distinguish them.

Declaring dependencies on packages for other arches

This ties in with the cross-only architectures; in order to provide readymade cross compilers, it is also necessary to have the associated header files and system libraries for the target platform handy in the package system. Using dpkg-cross, these can be easily created from the packages created for the target architecture, however to ship them along with the compiler, these packages would have to be autobuilt (difficult) and shipped along (which effectively duplicates them).

The idea would be to extend the syntax for Depends: (and the other fields as well) to allow specifying the architecture; if a package for a different architecture than the host is requested, dpkg-cross shall be used to handle the installation.

Update as of 2012-11: With multiarch, this idea is not whacky any more, but about to be implemented. Cross-architecture build dependencies will be usable after wheezy is released.

Declaring build dependencies per binary package

This would allow us to get rid of the circular dependencies when bootstrapping compilers (even native ones, although it is more complicated there). Basically, the current sequence to bootstrap a new architecture is as follows:





cross binutils



cross compiler



target (static) libgcc



target kernel

static libgcc


target startup code



target shared libgcc

startup code


target shared libc

shared libgcc


target runtime libraries

shared libc

All of this is complicated enough as it is, there are additional interdependencies in certain libcs, certain versions of the compiler etc. that have you iterate over the different sources even more.

The problem is that autobuilders cannot see more than one source tree at a time (note: that may be an alternate implementation possibly worth looking at), it is not possible to jump back and forth; having multiple packages with correct dependencies would duplicate a lot of source code.

So the idea proposed here is to have additional Build-Depends: declared in the per-package stanzas in the control file. The build target would, by default, not build these packages; autobuilders are supposed to see whether they can fulfill a package's build-depends and if so, invoke the "build-packagename" and "binary-packagename" targets in addition to the normal "build"/"binary" targets. If a package's build-dependencies cannot be fulfilled at this time, the source tree is not cleaned at the end of the build, and once the dependencies become available, the additional packages are built then.

Building embedded systems on the fly from a hybrid system

Not really a wacky idea, flashybrid and ADS root builder both use this method of starting with a full Debian install on disk and putting only the necessary files on flash. Both are inflexible and hard to use.

See RootSync for details of a varient of this approach that might work better.

Use Perl Version 1

Use the version 1, Perl interpreter instead of the current version, and modify all necessary scripts to utilize this. This will reduce the Perl footprint by a huge amount. The Perl1 interpreter is currently undergoing redevelopment.

Modify dpkg-divert to allow diversion of files to null space

This could be achieved by modifying the dpkg-divert package to omit installation of flagged files. An alternative method would be to use a nullfs filesystem, and diverting the files to the nullfs filesystem. (This would mean that the nullfs driver would need to be updated and incorporated into the current kernel.)

<!> Isn't this already solved by dpkg filters (--path-exclude)? Or maybe this refers to something else entirely, in which case it would be nice to clarify.