Emdebian, Squeeze, Grip and Crush

Emdebian 1.0 will be released based on Debian 5.0 "Lenny" but will only be available for one architecture (ARM) and in one flavour (a mix of what will become the flavours described below). Emdebian 2.0 (based on Debian 6.0 "Squeeze") will support the concept of flavours of Emdebian as well as a wider range of architectures.

Flavours of Embedded Debian

At the Extremadura meeting in 2008, ideas about how Emdebian can support a wider range of implementations created the idea of general flavours of Emdebian over and above the existing customisations and machine:variant support. See also http://lists.debian.org/debian-embedded/2008/09/msg00050.html.

The name of the next Debian release after Lenny gave perfect basis for the names of these flavours.

• Debian Squeeze
  1. Emdebian Grip - A light grip on Squeeze. Small amounts of squeeze, as few functional changes as possible and highest level of functional compatibility with Debian Squeeze. Intended to be primarily a native build environment, including support for building custom packages on an Emdebian installation as well as the ability to mix and match Emdebian and Debian packages with minimal effort.
  2. Emdebian Crush - The ultimate Squeeze - maximally squeezed with dependency changes, package name changes and a lot of work to ensure that Debian packages can still be mixed in.

The nature of Emdebian Grip

1. Native or cross-build, as appropriate.
2. Support for compilers and build tools, including interpreted languages.
3. No functional changes within libraries. This means not changing the options to ./configure in debian/rules.
4. Extending the upcoming TDeb support in Debian to the existing Emdebian TDeb support.
5. Use of "nodocs" support in DEB_BUILD_OPTIONS and extending support for "nodocs" within discussions around DEB_VENDOR as well as in the limited Emdebian package set.
6. Less pressure on ultimate installation sizes and package sizes. Devices running Emdebian Grip will need less space than Debian Squeeze but will need more space (including temporary space) than Emdebian Crush. To use the compilation support, devices will need considerably more space and RAM than a device running Emdebian Crush.
7. For greater compatibility, based on coreutils rather than busybox.

The changes in Emdebian Crush

1. Cross-built almost exclusively - Crush is targetted at machines that will not be able to build packages for themselves. Although packages could be included from other machines of the same architecture, the expectation is that many issues that could need to be resolved using a rebuild might not be easily tested on a similar but not identical machine.
2. Following on from 1, no support for compilers or build tools - no particular need to ensure that build tools exist in the repository or are necessarily installable on Crush.
3. Lots of functional changes where such changes are necessary:
   • where the disabled components simply do not cross-build or
   • where the disabled components bring in unwanted dependencies or
   • where the changes allow for functional package splits to retain functionality but change the dependency tree such that devices can selectively install only one or other dependency chain.
4. Same TDeb support as Grip.
5. Same use of "nodocs"
6. Incessant pressure to reduce final installation sizes, package sizes, dependency chains and support a variety of further customisations and machine:variant possibilities.
7. For greater size reduction, based on busybox. rather than coreutils

What next?

What happens to the names after Squeeze is ... unknown.

Whether devices can migrate from Debian to Grip and on to Squeeze is unknown. Migrations between Debian and Emdebian Grip should be practical. Migrations between Emdebian Grip and Emdebian Crush are likely to require a reinstall, especially when migrating to one of the more restrictive customisations of Crush.