Emdebian and Debian

Debian is a fantastic resource with its 14,000 packages and 11 architectures, but it's too fat for a lot of embedded and small-system use. Below we describe the emdebian process for producing a version of Debian that is smaller, but retains the as much that is good about Debian as possible. The packaging system, the licensing, the distributed development, the vendor neutrality, the multi-architecture support, the guaranteed freedom, the availability of source, the build system, the consistency between packages.

Unfortunately we can't just change Debian policy to mandate smaller packages, or allow the removal of important documentation, as that wouldn't suit most Debian users. And simply taking a snapshot of Debian and modifying the packages will mean our packages are different from those in Debian and we will get left behind as Debian continues to develop.

We need a scheme that allows emdebian to stay in sync with Debian as much as possible, whilst having fine control over package generation. To do this we need to keep emdebian package modifications in each package, maintained by package maintainers as much as possible. The initial modifications will be done by the Emdebian team in the form of emdebian targets in the debian/rules. These modifications are passed back to maintainers or hopefully can be persuaded to keep them up to date for their packages.

This is a huge undertaking but fortunately we don't need to do this for every package in Debian, only the relatively small subset that most embedded/small systems need. Much of the process can be automated, at least to a first approximation, and once the principle is proved we can hopefully get the maintenance of the emdebian targets mandated as part of Debian policy. However that's well in the future. Right now we need to set up the system, make patches, persuade maintainers and persuade ourselves that we have a practical and useful plan.

The Plan

This is the plan hatched during a discussion at Linux Expo, London 2003, by (primarily) Daniel Silverstone, Wookey, Vince Sanders, Peter Naulls, and Paul Hedderly, later modified by discussion on debian-embedded, particularly contributions from Erik Andersen & Liberty Young. So if you think it's rubbish you know who to blame. Critisism is welcome and changes may well need to be made as we try things out.

Initially we will work just with Debian 'base' packages in order to get a working infrastructure, and to keep the number of maintainers we are dealing with down to a reasonable number. Once the principle is established we'll include more packages.

Each (source) package will have emdebian-build and emdebian-install targets (for building and installing respectively). These targets will be used by our build infrastructure. Most will simply remove all the docs and other non-essential files such as examples & unused locale information. For some packages it will be best to change options to reduce the number of dependencies and/or be better suited to small systems. All packages will be built against uclibc instead of glibc. All packages will be built with -Os. Some secondary binary packages probably need not be built at all.

All this means that emdebian will have a different dependency tree to Debian, and auto-building Debian is already tricky due to many circular dependencies. Splitting out the documentation will remove many of these, but managing dependencies such that Emdebian remains buildable at all times will require care. A preliminary build of 550 packages with glibc has shown that the problem is manageable. Ensuring that build-depends are honoured for migration of a source package into Emdebian (unlike Debian proper's migration policy from unstable to testing) should help; so will keeping the total number of packages much smaller than Debian's. Advice from release gurus is welcome.

We need to

• Set up a build system (buildds)- Paul Hedderly volunteered a system. We will initially target i386 and ARM to keep things relatively simple
• Identify the initial Emdebian subset of Debian
• Make Emdebian targets for each package
• Persuade maintainers to incorporate the Emdebian targets
• Build away and see how well it works.
• Document the process of creating an emdebian target for each package
• Document the build system so that people can monitor it and reproduce it
• Develop emdebian package policy to ensure consistency and minimalism

Volunteers are needed for all these tasks, otherwise this scheme will not get off the ground. Roll up, roll up.

Native compilation vs. cross-compilation

Debian is currently all natively compiled because some packages are difficult to cross-compile. This is less true than it was, and most of the things needed for Emdebian should cross-compile properly. For many embedded developers cross-compilation is normal, and with underpowered target platforms is often essential to get things compiled in a reasonable time.

People using binaries pre-compiled by Emdebian don't care how they got built so long as they work, but for those who need to compile their own packages a cross-compiling option is usually necessary. Native compilation works better for some architectures than others - e.g. fast new ARM machines are available which make native ARM compilation relatively quick. Native compilation means maintaining more build machines and some of them will be slow, but it removes one source of potential problems, and is compatible with the rest of Debian.

Recognising the benefits of native compilation and the need for cross-compilation, the Embedded Debian project will use a native compilation setup combined with scratchbox, which lets compilation happen on fast machines with configure scripts and other compile-time executables run natively. This seems the most sensible way to go, giving us speed, no compile-time problems, and enough versatility for developers to cross-compile their own variants.

Documentation

There isn't any yet beyond this page. A detailed description of what developers need to do is one of the tasks.