[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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  <neroden@fastmail.fm>

Make sure your vote will count.

Reply to: