Re: Splitting dselect from dpkg -- acceptable plan?
Ian Jackson wrote:
>I still use dselect on all of my Debian systems and I don't want to
>switch to using apt.
Wow. Which acquisition method do you use?
CD-ROM? NFS? Harddisk? Mounted? Floppy?
(Perhaps you install dpkg-ftp or dpkg-multicd?)
>dselect is more than just a UI.
For most users, it's just a UI. Albeit a very clever UI which has better
handling of dependencies and installation states than its imitators, and I
certainly want to retain that. :-)
However, even if you oppose use of apt, dselect NEEDS to be a separate source
package. It will be impossible to find any volunteer willing to make any
improvements of any sort under current conditions. You're clearly not
I am volunteering to make it a separate package; the exact nature
of that package is not a vital matter for me, and if you want to keep it
'apt-independent', that's OK. I will not volunteer to work on it as the
conjoined twin of dpkg, and I'm quite sure nobody else will either.
Dselect is tied up with libdpkg, and any changes to libdpkg are dangerous because
they may break dpkg; however, libdpkg doesn't have a well-defined interface or a
shared library, or even a library exported in dpkg-dev, so dselect maintainers
can't just treat it as a "library we use".
This is the fundamental problem here. Libdpkg is a collection of functions many
of which are unrelated functionally to each other. Parts of it are divergent
depending on whether it's being used from C++ or C, and then there's this:
struct perpackagestate; /* dselect and dpkg have different versions of this */
Furthermore, I strongly suspect that the optimal version of many routines varies
between the needs of dselect and the needs of dpkg (apart from the routines which
are in fact only used by one or the other). In particular, many routines could
likely be sharply cleaned up for dselect, or even eliminated completely, by the
use of C++.
Based on the way the dpkg maintainers seem to treat dselect (as an annoyance), I
think they'd appreciate getting it into a separate source package, though.
Some code duplication is the price of this.
As long as libdpkg isn't a real library, dselect should be a user of dpkg, not a
conjoined twin. An alternate path would be to work to make libdpkg a real
library (or more likely, given its contents, multiple libraries), with a single
purpose, and a public, exported interface providing well-documented utilities for
that purpose. Since this hasn't happened in the long time dpkg has been
developed, however, I suspect that there's a fundamental reason it can't be done.
Nathanael Nerode <email@example.com>
Make sure your vote will count.