Producing udebs

How to patch

That’s actually quite trivial. Most packages from Josselin’s 1st and 2nd lists are libraries, and generating udebs for libraries is easy. Basically it boils down to declaring a new binary package:

  • Duplicate the libfooN entry in debian/control.
  • Add the -udeb suffix to the Package line.
  • Add a Package-Type: udeb line.
  • Make sure Section is debian-installer.
  • (Maybe) make sure Priority is only optional.

Now, populating it might depend on the considered source package, but thankfully, pkg-x11 packages are quite sane, using debhelper’s dh_install. So duplicating debian/libfooN.install into debian/libfooN-udeb.install is usually sufficient. It’s a bit trickier when dh_movefiles is used, but calling install and cp -r after the dh_movefiles call should be sufficient.

Next step, tweak shlibs for libfooN. Without that step, a libbarM package built against libfooN would get libfooN in Depends, which is not appropriate. The idea is to get libfooN-udeb instead. Trivial: add --add-udeb=libfooN-udeb to the dh_makeshlibs call.

Possible issues at that step:

  • debian/shlibs or debian/libfooN.shlibs is used instead of dh_makeshlibs. Trivial fix: feed its contents to dh_makeshlibs through its -V argument, and delete that file. Caveat: when it comes to applying a patch removing that file, make sure it’s actually removed, and not just empty. I’m going to file a bug about that, the default behaviour with empty files seems a bit buggy.
  • Several libraries are shipped: one can’t pass several --add-udeb arguments. Solution: use several dh_makeshlibs -p$pkg -V$depends --add-udeb=$pkg-udeb call. (I thought it was needed for libx11 but I can’t read, actually: libxcb1libx11-xcb1.)

Various checks to perform:

  • Make sure debian/libfooN/DEBIAN/shlibs is correct: it should have a udeb line. Example:

     libfoo N libfooN (>= some-version)
     udeb: libfoo N libfooN (>= some-version)
  • Make sure the generated udebs have no non-udeb packages mentioned in Depends. Since I’m still at the proof-of-concept stage, I’ve iterated when I encountered such additional packages, without checking what was actually needed. The idea is to get rid of extra stuff once the final needs figured out. Of course, one has to track down the dependencies to get the packages incrementally built and installed (for the updated shlibs files).


(These files might be moved around during the following steps, but this post shall be kept up-to-date and point to them at all time.)


  • Red box: package needing a patch.
  • Green box: package already udeb-aware.
  • Label with [n]: package patched at step N.
  • Label with a *: warning when patching, shlibs file to be removed.

Graphs are scaled down to 75%, click for full size.

Step 1:

Step 2:

Adding udebs to a d-i image

Basic d-i image

General guidelines (see d-i documentation for detailed installation, needed packages, etc.):

svn co svn:// debian-installer-trunk
cd debian-installer-trunk/installer/build
make build_netboot

If that breaks (e.g. due to missing packages), make sure there’s a similar entry in sources.list.udeb:

deb http://yourmirror/debian squeeze main/debian-installer

If everything goes well, the generated image should be available as dest/netboot/mini.iso, and tmp/netboot/udeb.list should contain the list of embedded udebs.

To give it a try:

qemu-system-x86_64 -cdrom dest/netboot/mini.iso

Actually adding udebs

Drop all additional udebs under localudebs/. Needed Packages and Packages.gz should be generated on the fly (but beware, secure apt is then disabled, even for non-local udebs).

Now, tell d-i we want some more packages. If all of them are wanted, one can do that:

for i in localudebs/*.udeb; do \
  dpkg-deb --showformat='${Package}\n' -W $i; \
done > pkg-lists/local

(Update: Thanks to Guillem for pointing out a better and cleaner way than dpkg --info $i|grep Package:|awk '{print $2}')

Generate a new image (note the rebuild part of the target):

make rebuild_netboot

Make sure they got added by looking in tmp/netboot/udeb.list and profit!

What’s next

Future steps include:

  • Making sure those udebs are actually usable.
  • Reworking Pango/Cairo/Gtk udebs.
  • Taking a look into X itself.

Stay tuned.