Table of Contents
A udeb (or micro-deb) is a special kind of Debian package. Technically udebs are very similar to regular packages: you can look at their contents using dpkg -c, and extract them using dpkg -x and dpkg -e.
The main difference is that a lot of policy requirements are waived. For example, a udeb does not contain a changelog, licence, manpages or md5sums[4]. The reason is to minimize size which is important as the installation takes place completely in RAM, with swap only becoming available after stage 4 of the installation (partitioning).
Another important difference is that udebs are not really meant to be uninstalled or upgraded.
The relaxed policy requirements are one of the reasons that udebs should not be installed on a normal system. The other reason being that it just doesn't make sense and it's likely to break things.
Two special classes of udebs should be mentioned here. However, covering these in detail is outside the scope of this document.
Kernel udebs are built basically by repackaging a regular kernel image
package. Reason is again to reduce memory usage: not all modules included
in a kernel image package are needed during an installation. Also, different
modules are needed in the initrd for different installation methods, remaining
modules can either be loaded later or optionally (by manual selection or
through dependencies). The package kernel-wedge
contains the toolset used to reorganize a kernel-image package into multiple
kernel (module) udebs.
Partman has a very specific structure and requires a fairly strict conformance to this structure for udebs that extend its functionality.
For components that are included in the main menu, the udeb will contain at least:
a postinst
a debconf template that contains the description for the main menu:
debian-installer/<component>/title Type: text _Description: <menu entry>
Other things like additional debconf templates, C programs, hook scripts can be added as needed.
A special type of control file worth mentioning is the
.isinstallable file. If a script with this extension
is present in /var/lib/dpkg/info for a component,
the main menu will run this script and only include the component in the
menu if the script exits 0.
Creating a udeb is not all that hard, especially if you use
debhelper. debhelper knows the
special properties of a udeb and will do the right thing by default at build
time. That is, if you don't forget to tell it you are creating a udeb.
The example below shows the debian/control file for a
udeb that is supposed to be included in the main menu. Note the special
“debian-installer” section.
Source: kbd-chooser
Section: debian-installer
Priority: optional
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Uploaders: [...]
Build-Depends: debhelper (>= 7.3.10), libdebian-installer4-dev (>= 0.41),
po-debconf (>= 0.5.0), flex | flex-old , bison,
libdebconfclient0-dev (>= 0.49)
Package: kbd-chooser
Architecture: i386 amd64 powerpc alpha hppa sparc [...]
Package-Type: udeb
Depends: ${shlibs:Depends}, ${misc:Depends}, console-keymaps
Description: Detect a keyboard and select layout
Installer-Menu-Item: 1200
The line Package-Type tells
debhelper to treat the package as a udeb. The
Installer-Menu-Item is added in the control file for
the udeb and will eventually end up in the dpkg
status file to help main-menu figure out that this
udeb should be included in the menu and in what order[5].
Packaging a udeb becomes a bit harder if it is derived from a regular
package but needs to be compiled with different compiler options (e.g.
some features disabled or a different optimization).
The main thing to always keep in mind when creating a udeb is size. It is very important to keep size as minimal as possible. This includes using tabs instead of spaces when indenting in scripts and not being too verbose in comments.
Creation of correct dependencies on library udebs depends on
“package type” support in shlibs files for libraries.
This allows dpkg-dev and debhelper
to automatically set correct dependencies on library udebs when a d-i
component that depends on them is built.
For example, the regular binary package zlib1g has
the following lines in its shlibs control file:
libz 1 zlib1g (>= 1:1.2.3.3.dfsg-1) udeb: libz 1 zlib1g-udeb (>= 1:1.2.3.3.dfsg-1)
The second line is specific to the package type “udeb”. This alternative line is used when dpkg-shlibdeps is called with the -tudeb option; dh_shlibdeps will automatically add this option when processing a udeb.
Generating the extra udeb: lines is supported by
dh_makeshlibs if the
--add-udeb="<udeb name>" option is used.
For example, the debian/rules file for
libusb contains the following line:
dh_makeshlibs -V -s --add-udeb="libusb-0.1-udeb"
[4] Of course, the source package for a udeb does contain a licence and changelog.
[5] See Appendix A, Menu Item numbers for the specification of menu numbers that currently are in use.