Emdebian and Debian

Debian is a fantastic resource with it's 10,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. But as soon as we make separate packages from those in Debian we will get left behind and emdebian and debian will diverge with emdebian failing to keep up. We need to have a scheme that allows emdebian to stay in sync with Debian as much as possible. 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 andpersuade ourselves that we have a practical and useful plan..

The Plan

This is the plan hatched at Linux World 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 and 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-indep and emdebian-arch targets, for architecture independant and architecture dependent parts. 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 changing options to reduce the number of dependencies and/or make things better suited to small systems will be in order. All packages will be built against uclibc instead of glibc. Some secondary binary packages probably need not be built at all.

All this means that emdebian will have a different dependency tree to Debian. Managing this so that emdebian remains buildable at all times could be tricky. Advice from release gurus is welcome. 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, as should keeping our total number of packages much smaller than Debians .

We need to

• Set up a build system (buildds)- Paul Hedderly volunteered a system. Doing it for i386 first should make things simpler (and quicker)
• 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 ul, roll up.

Native compilation vs. cross-compilation

This is a thorny question. 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 probably will cross-compile properly. For many developers cross-compilation is how they expect to operate. On the other hand if people are using binaries from emdebian they don't care how they got built so long as they work. Native compilation works better for some architectures than others - e.g. fast new ARM machines are available which make native ARM compilation a doddle. Native compilation means maintaining more build machines and some of them will be slow, but it removes once source of potential problems.

Starting with native buildd's, whilst working towards making emdebian cross-compilable seems like a sensible approach, but there is room for discussion on this point.

Documentation

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