EmdebianMetaData

The biggest remaining issue in making Embedded Debian is how to store and control package metadata which describes how to reduce package size, increase granularity, reduce the size of the essential package set, etc.

This page tries to document the issues and the pros and cons of the current active proposals.

The issues have been developed in discussion with emdebian and debian developers at the Extremadura Work Session, Debconf and ?LinuxWorld Expo, in 2006.

Composite method.

emdebian diff contains changes. changes kept in svn as individual patches, managed with quilt. Emdebian diff applied after debian diff, then standard build tools used on the result.

pros

cons

Mechanisms:

{{{ foo_1:2.3.4-5.6em7_arm.mdeb foo_1:2.3.4-5.6em7.diff.gz foo_1:2.3.4-5.6em7.dsc foo_1:2.3.4-5.6em7_arm.changes }}}

Status: Mostly already achievable with normal Debian tools - except that the final archive needs to be renamed to use the .mdeb suffix at the final stage.

Problems: May require small changes to some .deb handling programs like reprepro. There has been a request to separate the emdebian diff.gz contents from the Debian .diff.gz contents - treating Debian as upstream of emdebian. This needs tweaking in the build scripts, possibly via the wrapper script below. Note that building such a package from source would then need both .diff.gz files and this could require further changes to the debhelper scripts, e.g. in the generation of the .changes file. In some (most?) situations, the emdebian .diff.gz will be empty - most changes being implemented by the build scripts.

  1. Wherever possible, emdebian will use standard Debian packaging scripts - only tweaking those related to the content needing to be removed or ignored in emdebian packages. i.e. the burden of changes has moved from Debian developers to emdebian developers. Packages like cross-get and dpkg-cross can be further enhanced to ensure the correct versions of the debhelper tools are used. Overall, this leads to changes in fewer files than using the $DEBIAN_DIR approach, as well as less duplication.
  2. Those packages that need further customisation can have patches stored in the emdebian SVN repository. An emdebian build script - a wrapper for pdebuild - will checkout and apply the patches before debian/rules is called. This is vital because using existing patch methods like CDBS and dpatch relies on debian/rules being called to perform the patch. In order to successfully patch debian/rules itself, the patch process needs to begin before debian/rules is called. The repository needs to hold patches on a per-source basis.

Status: cross-get can become apt-cross with normal apt functionality so that it can support a wrapper for pdebuild (empbuild) that downloads, cross-builds and installs dependencies in the chroot when building emdebian packages. This is in current development (Nov 2006).

  1. Unlike Debian packages, emdebian packages will not have individual emdebian maintainers. Instead, any emdebian developer will be able to update the emdebian customisations for a particular Debian package, e.g. when a new version is uploaded to unstable.
  2. An emdebian buildd can then package and upload archives to the emdebian repository to remove the delay between packages reaching testing and being built for emdebian.

Overall, this method uses the best of each of the previous ideas but large amounts of work remain.

A useful thing to do would be set up an emdebian BTS. Repackaging Debian archives through automated systems can cause mysterious bugs.

$DEBIAN_DIR

<explanation/example> - used by STAGv2 and STAGE

con:

pro:

udebs

<explanation/example> - used by Debian-installer

con:

pro:

Just change /debian files

con:

pro:

<explanation/example> - used by SLIND

In fact this is really a variant of the $DEBIAN_DIR example and could be implmented that way too(this assertion needs testing)


CategoryEmdebian