Time to rewrite dpkg
Hello, esteemed members of the Debian enthusiast community!
Over the last year and a half, as I have been involved in the Debian
project, dpkg's shortcomings have been becoming ever more clear to me.
Anybody who has worked any significant amount on dpkg knows that its sources
are extremely brittle, and that its upstream maintainence is lax.
At this time, rpm is regularly having new features and bugfixes
integrated with its codebase. Dpkg, howevver, is long overdue for a new
release, and even when that happens most of its critical bugs won't be
fixed; they simply can't be without upsetting a great portion of its
internal workings.
This is what's called brittle code. it's been modified too much;
It's written in an algorithm-oriented language where the slightest
modification can adversely effect all of its being. Changes are difficult
to make correctly.
So, whether or not I recieve the approval of this community, I'm
going to be working on a complete rewrite of dpkg. No, it won't even
*resemble* the old dpkg; I guarantee it to become contraversial. I'll let
the masses decide whether it warrants trashing the old for the new.
Notably, I'm going to be writing it in C++. This will add about 270k
to the boot disks' root image, but as the floppy install methods are for the
most part phasing out under the shadow of easier methods, I'm not going to
lose any sleep over this. libstdc++ can be minimized for static linkage
anyway.
Why C++? Well, personally, I have been seeing all of these
applications pop recently that are for package management, aside from dpkg.
Examples include dconfig and apt. Other ideas have been floating about, like
source dependencies and binary diffs.
I say that most of these applications would benefit greatly from
having access to all of dpkg's functionality and variables, so nobody has to
reinvent the wheel. I want to make all of these a part of dpkg.
Now WAIT! you say. We can't bloat dpkg! Well, we don't have to. It's
called modular software, and we have this capability in linux today. dpkg
should be able to accept addons at runtime, or to override default behavior
by a configuration file explaining where important methods exist.
Consider the benefits. First, dpkg comes as a 350k executable,
containing nothing but basic logic for commandline arguments and a static
link of libstdc++. Apart from that, libdpkg is required for dpkg to function
properly; This library defines all behavior for operations on packages and
the package/status databases.
Now, consider: If I want dpkg to be able to install files via http,
I can just plug in the appropriate module and supply the necessary
arguments. Now, consider if apt were a module: both dpkg and every frontend
written for it would inherit functionality for all available file retrieval
methods. This would eliminate much of the kludgery involved with coming up
with installation methods for dselect.
Consider again something more complicated, like bindiffs. Supplying
the appropriate arguments (--unpack-bindiff --retrieve-bindiff) would cause
dpkg to load the 'bindiff' module to override every bit of unpacking and
retrieval logic. Then, apt and all dpkg front ends would automagically
recieve this feature! This is the beauty of polymorphism in OO design.
dpkg will remain small, but extensible. The package manager is the
distribution, and I think ours has been neglected too long. Anybody with
constructive feedback and ideas is encouraged to respond, but negative
responses will be ignored. Whether or not the community approves of this,
I will pursue it, and let the chips fall where they may.
--
..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org....
Berlin: http://www.berlin-consortium.org
Debian GNU/Linux: http://www.debian.org
"...Nothing astonishes men so much as common sense and plain dealing..."
-- Ralph Waldo Emerson
Reply to: