Re: dselect complaints
Raul Miller writes ("dselect complaints"):
> Ian Jackson:
> > I'm not interested in hearing any more complaints or even extensive
> > suggestions for improvement, unless the person complaining is
> > volunteering to do the work on a new interface.
>
> Along that line, could you (when you have time) provide a few pointers
> on how you see the code structure? In other words, where should a
> person focus attention when re-designing the user interface? [Hints
> and/or reference material here -- nothing major.]
There are three layers to dselect: firstly, there is the dselect
program itself. It has the main menu, and implements the [S]election
list (which is much of the bulk of the program). It also implements
the menu for selecting between [A]ccess methods.
When you select and access method, or when you hit [U]pdate or
[I]nstall, dselect runs the second layer - the appropriate access
method. These are scripts which know how to find things that need to
be installed, and present them to dpkg with a set of options
(currently -iGROEB) that are suited to installation from dselect.
These scripts also have to know how to ask dpkg which packages need to
be installed at the start to satisfy predependencies, and make sure
that they do get installed this way.
dpkg itself is the third layer. It is called by the access methods,
of course, and also directly by dselect when you hit [C]onfigure.
You can find the scripts in /usr/lib/dpkg/methods, or in the methods
subdirectory of the dpkg source tree.
dselect tells dpkg and the access methods what to do by modifying the
`want' flag in the status file: this has (now, 1.2.0) five values:
unknown - the user hasn't said whether they want the package
install - the user wants the package installed or upgraded
remove - the user wants the package removed (but doesn't want
to remove any existing configuration)
purge - the user wants the package to be removed completely
hold - the user wants this package not to be processed
This modification is done by the [S]elect option in dselect.
Currently the disk access method (which is the one most people use)
implements the reading of this flag by giving dpkg options that cause
it to ignore packages whose selection state is inappropriate.
(--selected-only, --refuse-downgrade, --skip-same-version &c).
dselect tells the access methods what they're to do according to the
spec. for the interface between them, which I've posted a couple of
times. I've copied the spec. to the doc subdirectory of the dpkg
source. If there's demand I'll install it in /usr/doc/dpkg.
There are three things that need to be done, but I think they can be
done without changing the structure or the interfaces between
different parts of dselect/dpkg:
1. The disk installation method needs to be made more efficient in the
case where only a few packages are to be upgrade/installed and the
Packages file (which was supplied in [U]pdate and copied to
/var/lib/dpkg/available) is accurate.
2. We need to put the [A]ccess/[U]pdate/[S]elect/[I]nstall/[R]emove
options in a separate `expert' menu, and have the main menu be a
task-based scheme with options like `add package(s)', `remove
package(s)', `upgrade'.
These task-based options should go through [A]ccess (possibly
confirming an earlier selection, and possibly with a different
interface for access method selection), [U]pdate, a revised selection
procedure (see 3.), [I]install and [R]emove in order, without having
to ask the user to tell them to do so. (Confirming what they're about
to do would probably be useful, of course, but the options should be
`OK, continue' and `abort'.)
3. We need a new package selection interface that does more or less
the same as [S]elect currently does but presents the user with less
information and fewer choices at once. I posted a sketch design of
this earlier; I'll repost it if there's interest.
This part is where almost all the work is, but it really is essential
to make a significant difference.
4. We may need a new status flag or something `unasked', which means
that the selection interface didn't ask the user about a particular
package and so the access scripts and dpkg shouldn't touch it. This
may need to be separate from the normal `want' flag, so that the
system remembers your previous settings for packages (when upgrading,
for example) even when it isn't processing them (because, for example,
the package wasn't updated at the time and so wasn't presented to the
user).
> [Yes, I know it can be a big mistake to jump into design work before
> the analysis work is complete. But they can happen concurrently and
> it's often a good idea to get the biggest problem solved before going
> on to the next stage. In my mind, at least, I think I know what I'd
> consider the two biggest problems.]
I'd also like you to try out the [S]elect in dpkg 1.2.0. It has some
problems with dependencies for on-hold packages, and a few other
misfeatures, but it displays much more information about what is
available and allows you to organise the display in many more ways.
Of course it tends now to be even more experts-only, because of the
additional number of options ...
> Also, if it turns out that dselect needs another internal interface to
> the underlying data, how would you prefer this kind of thing be
> approached (again, just looking for a few simple options, and maybe a
> way of locating the right source module -- nothing major).
I think that if you're writing in C or C++ you'll find my routines in
the dpkg lib directory quite adequate (and indeed I'd strongly
recommend using them).
If you want to program in some other language then you'll find that
you may need to do quite a bit of data structure management (having
the dependency graph in some nice backwards-forwards fashion is pretty
essential), and we'll have to keep your parsing/writing code for
/var/lib/dpkg/{status,available} in step with mine.
Ian.
>From ian Sun May 14 18:21:53 +0100 1995
To: Debian developers list <debian-devel@pixar.com>
Subject: dselect installation method scripts
Below is a (somewhat amended) repost of the posting I made a little
while ago about the interface between dselect and the installation
scripts it can run to extract packages.
Carl Streeter has some hard disk scripts that look fairly good (I
haven't tested them). Anyone else looking to write such scripts
should see his code (Carl, can you upload them please ?).
Howevever, there are a few points to note:
* Each set of scripts can support several `options' as they're called
- this saves having different code for the CD-ROM, hard disk, &c
methods.
* You have to supply a /usr/[local]/lib/dpkg/methods/<method>/names
file listing the options - see below.
dselect *will* look in /usr/local/lib/dpkg/methods as well as
/usr/lib. Put your scripts there until you send them to me for
inclusion in dpkg.
Details if the installation method handling is below, and in
method-scripts.txt; an example `test' method that just shows you how
to write a `names' file and how dselect reacts is available as:
ab2022c57a1198838034c5f87ea501b1 dselect-example-test-method.tar
-rw-rw-r-- 1 ian ian 10240 May 14 18:19 dselect-example-test-method.tar
NB that the code in dselect to select and call installation scripts is
ALPHA !
Ian.
Each `installation method' will have three scripts:
* Setup installation parameters.
* Update list of available packages.
* Unpack.
Which set of scripts is to be used is selectable by the user, from the
`[S]etup' menu option. Basically, the user hits `Setup', gets
presented with a menu of choices and picks one.
This (a) sets that `choice' to be the default installation method and
(b) runs the `setup' script for that choice.
The setup script should prompt the user for parameters like the site
to NFS-mount or FTP from, the directory to use, or the directory or
filesystem where the .deb files can be found, or the tape or floppy
device to install from. It should store the responses under
/var/lib/dpkg/methods - see below.
The update script should obtain a list of available packages if
possible (this is the Packages file from the FTP sites), and copy it
to /var/lib/dpkg/available. Be careful not to overwrite the available
file if something goes wrong - I'd suggest copying to `available.new'
and renaming. If no available list is available :-) it should print a
message saying so.
The unpack script should feed all the available .deb files to
dpkg --unpack --no-also-select
(the --auto option may also be useful here). In the future there will
be a mechanism to allow (for example) a floppy-based installation
scheme to tell the user which packages are still to be processed; in
the meantime you should just keep going until the user says `stop'.
If any of these scripts needs to display a message for the user, it
should wait for the user to hit `return' before exiting so that
dselect doesn't immediately rewrite the screen.
If a script gives a non-zero exit status dselect will print a message
about it and prompt the user for an acknowledgement. If it exits with
a zero exit status then dselect will immediately go back into curses
and any message that the script printed just before exiting will not
be visible.
The scripts will be kept in /usr/lib/dpkg/methods/. Each method
should have a directory under methods, containing:
`names' - a list of `user-visible options', see below.
`setup', `update', `unpack' - executable programs.
`desc.<option>' - description file.
A method may provide several options on the `main menu' with different
behaviour. For example, there might be a generic get-packages-by-FTP
method which might provide entries in the main menu for installation
directly from one of the Debian mirror sites as well as for
installation from a user-specified site.
The `setup', `update' and `unpack' will be invoked with three
arguments.
The first argument is the directory with the dpkg status information,
usually /var/lib/dpkg. They should $1/methods/<method-name> to store
their data (remember that the user can give a --admindir option to
dselect).
The second and third argument are the name of the method and the
option within that method, respectively. This information is provided
by dselect (from the user's choice of installation option).
`names' will be formatted as a list of lines, each containing:
<sequence> <option> <summary>
<sequence> is a two-digit number that will be used much like rc.d
prefixes to control the order in the main menu. If in doubt use 50.
<option> is a name which will be passed to `setup', `update' and
`unpack' as their third argument (see above).
<summary> is the menu entry string.
Each option may have an extended description in `desc.<option>'. This
should be formatted like a Description: field entry *shifted one
character to the left*.
/var/lib/dpkg/methods will exist, and a method may use a
/var/lib/dpkg/methods/<method> directory or file (or <method>.* files)
to store its state.
<method> and <option> must follow the rules for C identifiers.
-- Ian Jackson 14th May 1995
Reply to: