apt on handheld issues

[Klaus Weidner <kw@w-m-p.com>]

Hello,

I'm currently busy re-packaging my Debian environment, and again running
into some issues with apt's rather wasteful use of disk space.

Some of these issues are already mentioned on Matt Zimmermann's page:
	http://people.debian.org/~mdz/zaurus/dpkg.html
Here I'm focusing more on apt than on dpkg.

The following "sources.list":
	deb http://ftp.debian.org/debian testing main contrib non-free
	deb http://nonUS.debian.org/debian-non-US testing/non-US main contrib non-free

results in a rather large amount of disk space used by apt:
	7680    /var/lib/apt/lists
	6040    /var/cache/apt
	13724   total

This is in addition to the "available" information saved by dpkg:
	4312    /var/lib/dpkg/available
	4312    /var/lib/dpkg/available-old
	8624    total

So that's a total of 22MB being used for redundant package information
that could be stored in 2 MB gzipped. If you would want to keep
information about 'stable' and 'unstable' and the corresponding sources
as well, the disk space needed increases correspondingly.

I've been able to mitigate it somewhat by removing the description
sections from the Package files, which approximately halves the space
needed by apt. But it's still a large chunk of storage.

One approach I've been thinking about is writing an alternative "apt-get"
implementation in Perl that supports the basic operations necessary
(update, dist-upgrade, install, remove) and works directly with gzipped
package files, without a separate database. Since my simple
shell+egrep-based solution in the "chroot-debian" bootstrapper worked
surprisingly well, I think that would be a reasonable approach,
especially if you don't try to support complexities such as pinning. But
that would break any frontends that use apt library functions, since I'd
only be supporting the command line interface.

Another issue is that it's impossible to store the apt database on a
jffs2 filesystem, since that filesystem doesn't support the mmap
operations (shared writable?) apt needs. That's unfortunate since the
data would really benefit from filesystem-level compression.

Is anyone already working on issues such as these, as well as the others
Matt mentioned? Supporting different target filesystems for packages
(similar to what ipkg does) would also be very nice to have.

-Klaus