Re: "dselect" replacement team
I thought the plan was to produce a new user interface for dselect ?
I see a lot of talk about how dpkg's on-disk data structure should be
changed - in particular, plans to change /var/lib/dpkg/status
somehow. I think that these plans are very ill-advised, and that
anyone who thinks we should change /var/lib/dpkg/status to be a binary
file should
(a) consider what purpose they really have in mind;
(b) determine whether parsing time for that file really is
significant as a proportion of dpkg's startup (hint: it isn't);
(c) consider whether they are an appropriate person to be involved in
this entirprise if they're willing to throw away working parts of the
system without a good reason and without understanding the issues or
code involved.
IMO the only change requred for the user interface improvements to
code which is part of dpkg is to have the dependency checking code as
a function in the libdpkg section, rather than several varying
implementations throughout the code. This change can only be made by
a C expert with a very good understanding of dpkg's internals and
specification. Apart from that, no changes to dpkg should be
required.
dselect should continue to call dpkg to get dpkg to do the actual
installastion and removal; this way dpkg can continue to ensure that
the system doesn't get hosed and mistakes in dselect are less
important.
Doing this will also ensure that there is nothing that dselect does
that cannot also be done from the command-line, which I think (and, it
seems, others think) is an important property which should be
preserved.
There is a problem with dpkg's startup time, duie to the structure of
the *.list files in /var/lib/dpkg/info. I have some ideas about how
to fix this, but it really ought to wait for me to do it, because
there are several complicated issues involved.
Ian.
Reply to: