Emdebian Grip Guide

Preparing a Debian-compatible distro

This Guide seeks to highlight some problems which may affect the maintenance of an Emdebian Grip server and the reasoning behind the workarounds.

[ functionality] [ overrides ] [ building Grip ] [ testing suite ] [ handling a release ]

Functionality of Emdebian Grip packages

There are some things to consider when looking at using Emdebian Grip for your situation.

For a summary of why these changes were made and the kind of devices for which Emdebian Grip may be suitable, see the section on using Embedded Debian with single purpose versus general purpose computers.

No source changes

Emdebian Grip does not make any modifications to sources, so if you are expecting Emdebian Grip to give you a less resource-hungry web browser, that means choosing a different web browser like midori as there will be no change in how iceweasel / firefox behaves just by changing it to a package from Emdebian Grip. The package will be smaller but it will behave just as in Debian.
Minimal extra packages

Emdebian Grip does not provide new source or binary packages, other than a few helpers or task related meta packages. Therefore, your package selection needs to be based on Debian. If the package does not exist in Debian, you will need to build it for your target yourself as a normal Debian package build.
Fewer packages

Emdebian Grip uses a subset of Debian packages - roughly around ten percent. See the Emdebian Grip search page for information on which packages are available.

See below on Architecture Neutrality for how existing Debian packages can be converted and Package choice for information on selecting the packages to use.
Package choice and device types

Debian does not contain a lot of software designed for mobile phones or tablets - much more for desktops and servers. There are usually kernel patches required to operate most phone hardware. This has an effect on what kind of devices can be used with Emdebian Grip. Many smartphones could probably boot Debian and / or load Debian as a root filesystem, the problem would be that the phone itself is unlikely to behave as a phone. Similarly with a tablet, the graphical interfaces in Debian may not be as friendly over a touchscreen interface without a stylus. The main problem with such devices is that by the time anyone does the work to free up the software to provide support for it in the Linux kernel, the device is obsolete.

Everything depends what you want the device to do after changing it to run Debian or Emdebian. The simplest option is to install a test Debian system, pare down the package selection to only the set necessary for the device and play with it on your desktop machine, possibly in a virtual environment on your native architecture. For simpler systems, just do a test chroot using debootstrap or multistrap, again, for your native architecture. It doesn't matter if you base the test system on Debian or Emdebian Grip - you can always change the apt sources to point at one of the Emdebian mirrors and upgrade your test system to get some idea of the overall space saving for your particular usage.
Custom UI support

Emdebian Grip is a standard Debian system, just with a smaller storage requirement, so building for Emdebian Grip is the same as building for Debian. Any custom UI which you can prepare can be installed on top of Emdebian Grip.

e.g. there is an armel build of QtEmbedded 4.6 available if what you need is a Qt GUI without an X server. Details of the changes relative to the qt4-x11 package in Debian can be seen in Emdebian SVN.
Architecture neutrality

Everything about Emdebian Grip is architecture-neutral. Any package for any architecture can be converted to Emdebian Grip on your standard desktop machine using apt-grip< /> from the emdebian-grip package in Debian.

This is the simplest way to add specific Debian packages to an Emdebian Grip device. If there are particular packages which would be generally useful in Emdebian Grip, use the buildd.emdebian.org pseudo-package in the Debian BTS to ask about adding the package to Emdebian Grip. The main criteria are the number of other packages which would need to be added as dependencies and the general suitablility of the package for Emdebian.

Use of override files

Although source packages usually determine the Priority of each binary package built from that source, Debian also uses override files to change priorities to fix other problems - without necessarily changing the actual setting in the package.

Override files have useful benefits within Emdebian Grip, so the functionality has been incorporated into the emdebian-grip-server scripts that are used to maintain the Emdebian Grip repository. The content of the current override files can be found at:

Unstable: override.sid.main

Testing: override.lenny.main

To handle overrides, use a combination of emgrip-dupes and grip-override-replace.pl. Duplicates are a problem for repository updates, so always check for and remove duplicates using emgrip-dupes. When a package from Debian uses a Section that puts the binary package into an inappropriate component for Grip (e.g. dbus is Section: devel), set the override for unstable and use grip-override-replace.pl to action the override in the repository itself.

Architectures: override.architectures contains references to packages which are Architecture: all but depend on packages which are Architecture: any and only present on certain architectures. This file is used by grip-overridearch.pl to prevent unsatisfiable dependencies by removing the Architecture: all package where the dependency is missing.

Does Grip recompile packages?

No. It might look as if em_autogrip is building packages when viewing the output or build logs but it is simply using dpkg --build to repack the archive after removing files determined by the DEB_BUILD_OPTIONS passed to emgrip.

emgrip itself is based on dpkg-cross code and is functionally similar to how lintian operates - except that once the processing is finished, dpkg-cross and emgrip repack the .deb with modified contents whereas lintian simply throws the content away.

testing support.

em_autogrip can setup a basic repository, but adding a testing repository will require some manual configuration of reprepro, including the override support above.

handling releases

If your repository uses a testing repository, there is probably an expectation that testing will, eventually, become stable. Emdebian includes a short overview of the release process.

Back to the Emdebian Project homepage.