Debian handheld projects: status update
I'm going to try to get out the status update that I promised. If you
follow up to one of these topics only, please change the subject line to
make it easier to keep track of the threads.
This will mostly be a dump of things that I've been thinking about with
respect to Debian on handhelds (in general) and the Zaurus (specifically),
and a brief record of where we've been and where we stand on current
development. I have not been able to keep up with all of the projects
involved, so if those working on them would like to step in and provide more
detailed updates, that would be great.
Opie
----
rkrusty's opie packages are coming along wonderfully, and are progressing
into Debian unstable. Some Opie folks have been kind enough to join us here
to help out, so this looks like it will become a very solid base.
X11
---
I think that it will be valuable to provide a more traditional X11-based
desktop for the Zaurus, in addition to an Opie-on-framebuffer setup. This
will make it possible to run many of the X11 applications in Debian on
Zaurus without modification. Some time ago, I uploaded an xfree86-tinyx
source package which provides the TinyX X server built from the standard
XFree86 sources, which runs on the framebuffer and includes iPAQ touchscreen
support. I have a small daemon which translates the Zaurus' touchscreen
events into iPAQ touchscreen events, so this actually more or less works.
I'll need to update it to XFree86 4.2.0, and have a something to start it up
at boot time, and perhaps a mechanism to select between this, opie-fb, and
whatever else comes along.
Chroot-Debian
-------------
Klaus Weidner has posted a detailed update to the list already. This
represents one approach for grafting Debian onto a handheld without the
effort and complexity of stripping it down, for users with storage expansion
cards. I haven't had tried it yet.
This also has the advantage of not requiring writes to the internal
flash...I understand those devices have a limited number of write cycles in
their lifetime, and I imagine things could get rather ugly if it started to
wear out. Has anyone experience with this issue in practice?
GPE
---
This is an X11- and GTK-based desktop project, over at
http://gpe.handhelds.org. I understand it's used by some Familiar users on
the iPAQ. Phil Blundell has packaged some of the software for Debian.
It would be nice to have this as an option at some point in the future, so
we should keep it in mind when thinking about how to set up desktop
operations.
Kernel
------
Most folks, as far as I know, are using the 2.4.6-rmk1-np2-embedix kernel
sources from Sharp, which were used for the stock software as well. This
kernel is, to my knowledge, the only one for which the binary-only drivers
for the SD/MMC slot (sharp_mmcsd_m.o). Chris Larson is working on adding
support for the Zaurus to mainstream kernels (http://linux-cl.bkbits.net/),
which looks very promising....maybe he'll give us an update. ;-) When it
makes sense to do so, we'll want to package a kernel-patch-collie or such
with the necessary patches for 2.4.x, and build some sort of kernel-image
packages. Traditional ones won't be particularly useful, since the kernel
isn't stored in the filesystem on the Zaurus, but we'll want precompiled
kernels around for use in building flash images and such.
Packaging Issues
----------------
The core challenge is, of course, storage space. Even with expansion cards
and microdrives, these devices have far less storage available than even a
low-end laptop or desktop. There are many strategies available to address
this challenge, including:
- Building specialized binary packages based on source package
modifications, for example disabling support for hardware and software
which does not make sense on a handheld, excluding documentation, tweaking
dependencies, etc. There is some infrastructure available for automating
this kind of maintenance, using version control systems and apt-src, but
this approach gives a lot of flexibility.
- Installation-time filtering of binary package contents (aka dpkg exclusion
support). This requires modifying dpkg, but the ability to do simple
pattern-based exclusion of files is very powerful and simple to maintain.
Handheld-specific exclusion profiles could be supplied for any package at
any time, without modifying it, and users could selectively use these
profiles on a per-package basis. This is planned as a future dpkg
feature, but if we are to make use of this functionality in the near
future, we would probably need to work this out ourselves.
- Expanded storage. SD cards, CF cards, microdrives, etc. can easily be
used to store data which will not fit in internal storage, but there are a
lot of packaging challenges here. For example, can a package installed on
a removable device satisfy a dependency? What happens to the dependent
package if the media is removed? How will we manage merging the two
filesystems into one tree (symlinks, union mounts, etc. dpkg hooks will
almost certainly be required)? ipkg, a small package manager used in the
stock software, OpenZaurus, etc., allows for software to be installed on
removable media by setting up and removing symlinks when media is inserted
and removed, and storing a package database on the media (I think). For
the Debian packaging system to work correctly, all of the package status
data must be available in one place, at least when package installation
and removal are being performed.
Bootstrap
---------
In order to provide up-to-date installations from scratch, we will need an
automated process for constructing a flash image suitable for the Zaurus.
This is not too difficult with debootstrap; I use this to get started:
---
#!/bin/sh
#
# Don't need ipfwadm, but it's smaller than any of the alternatives and
# dependencies currently require one of them
#
debootstrap --arch arm \
--exclude \
setserial,console-tools,console-common,console-tools-libs,console-data,\
logrotate,sysklogd,gettext-base,fdutils,klogd,libperl5.6,pppoe,pppoeconf,\
manpages,info,man-db,groff-base,modconf,exim,mailx,at,libldap2,libsasl7,\
libpcre3,libgdbmg1,libident,cron,ipchains,iptables \
--include ipfwadm
woody $1 $2
---
and then install software by hand from there. Of course, this tree will
likely be too large as-is, or at least after must-haves like pcmcia and
friends are added, but trimming a few things like this:
# Remove cruft from using the tree for a live system
rm -rf /tmp/initrd/var/cache/apt/*.bin \
/tmp/initrd/var/cache/apt/archives/*.deb \
/tmp/initrd/var/lib/apt/lists/debian*
find /tmp/initrd \( -name '*~' -o -name '*.dpkg-*' -o -name '.nfs*' \) -print0 \
| xargs -0 rm -f
# And remove some useful stuff that we can live without
rm -rf /tmp/initrd/usr/doc /tmp/initrd/usr/share/doc \
/tmp/initrd/usr/man /tmp/initrd/usr/share/man \
/tmp/initrd/usr/share/locale \
/tmp/initrd/var/lib/dpkg/info/*.md5sums \
/tmp/initrd/var/lib/dpkg/*-old \
/tmp/initrd/etc/X11/xkb \
/tmp/initrd/usr/X11R6/lib/X11/locale/[^C]* \
/tmp/initrd/usr/X11R6/include/X11 \
/tmp/initrd/sbin/fsck.ext3 \
/tmp/initrd/usr/bin/localedef \
/tmp/initrd/usr/bin/apt-cdrom \
/tmp/initrd/lib/libslang* \
/tmp/initrd/usr/share/info \
/tmp/initrd/usr/X11R6/lib/libXft.so* \
/tmp/initrd/usr/lib/libfreetype.so* \
/tmp/initrd/usr/lib/gconv
goes a long way. This is more or less how I built the Debian Zaurus
experimental images that I've been distributing.
Random Ideas
------------
Depending on what resources we have at our disposal, we could go along way
toward customizing Debian for handheld systems. Some possibilities include:
- Providing packages which work with a smaller C library (dietlibc, uclibc),
which would require (at least) an autobuilder of some sort and probably
patches to some packages to allow them to build without glibc
- performing shared library reduction, either on the binary packages
themselves, or at installation time. boot-floppies and debian-installer
have some code for this
- The core packages will obviously go in Debian proper, but it is quite
likely that we will want (or need) to distribute modified versions of
packages which are not appropriate for Debian. These will probably go on
people.debian.org for the moment, but we should think about ways to have
these packages coexist nicely within Debian, or to provide them as a
branch from the corresponding Debian packages, while merging in Debian
updates.
- Your thoughts here...
--
- mdz
Reply to: