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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
