The debian-installer is an effort to redesign and rewrite debian's
installer for woody. It's just getting started.
We've decided that the new installer will be modular, where modules are
maintained by separate people, and can be installed into the installer
itself while it is running, to give it additional capabilities (like the
ability to partition a disk, or run an interactive shell, and so on).
These modules will themselves be debian packages.
So we need some rudimentary package management tools to be part of the
base of the installer. Dpkg, at around 240k, is much too big. The target
size is more like 24k. I'm calling this stripped down dpkg "microdpkg".
It is not intended to be fully compatable with dpkg, or to be a
full-fledged replacement for it; it will support only those dpkg
features we need to manage packages in the installer.
I think that just like dpkg, it should be split into two programs:
microdpkg-deb to handles the low-level unpacking of packages, and
microdpkg, to do dependency checking, and so on. Maybe this will turn
out not to make sense; some space might be saved if the two were
combined. On the other hand, Erik Anderson might want to put
microdpkg-deb in busybox -- Erik?
If it is a seperate program, microdpkg-deb should implement the following
switches, with the same behavior as dpkg-deb:
(More may be added later, as needed.)
--info, -I
--field, -F
--extract, -x
It is expected that it will use busyboxes ar, gzip, and tar implementations
to handle pulling packages apart.
microdpkg will use microdpkg-deb to implement a subset of dpkg's
functionality. It will just implement the following switches:
(More may be added later, as needed.)
-i, --install
-r, --remove
It will maintain /var/lib/dpkg/status and /var/lib/dpkg/info/* in a
manner compatabile with dpkg. It will not support alternatives, diversions,
and so forth. It will not support conffiles, nor will it support purging of
packages, nor will it check to see if multiple packages contain the same
file. It will not support preinst and prerm scripts, and will probably
also not support the maintainer script error unwinding done by dpkg.
In package metadata, it will use the following fields: Package, Status,
Depends, Provides -- and will ignore the rest. (Thus, no suggestions, no
reccommendations, no pe-dependencies, no conflicts.) It need not support
OR'd boolean dependencies, or versioned dependencies.
They will be written in C, or perhaps, in POSIX shell script (without
any external commands except ar, tar, gunzip, though..).
I'm looking for a few people who'd like to write this in the next week
or so. I think Randolph Chung may have already done some preliminary work.
If you'd like to help, make sure you're on the debian-boot mailing list
and reply to this mail.
--
see shy jo
