Re: comments on dselect
Michael E. Deisher writes ("Re: comments on dselect"):
> Personally, I'd rather see the default behavior changed and the intro
> screen explain how to get all the recommended packages. There are a
> lot of them and some of them (e.g, gcc) are huge. Perhaps we just
> need to reevaluate our criteria for a package to be considered
> "recommended".
For expert users, the default is not relevant, as they'll go and
(de)select what they want anyway. Therefore, the default is only
relevant to novices.
Let me try to identify what the problems are with each possible
default, how often these problems will occur, and how bad the likely
consequences are going to be:
The potential problem with having the default be all the packages is
that the user will run out of disk space during the installation.
This is likely to happen on small systems (which are now getting
rarer), and since the user will be aware of the need to set aside
enough disk space we can just tell them what the disk space
requirements for a `standard' installation are. This will hopefully
confine the problem to hasty or naive users on small systems.
When it happens it will be fairly obvious what happened, and the user
is likely to understand it. They're likely to come up with an
appropriate response (like removing some packages, or doing a
reinstallation with a larger partition, or learning how to deselect
the packages they don't want).
I therefore don't think that the incidence*severity here is too bad.
The potential problems with having the default be only the essential
packages are (a) that the user will fail to install the software that
they believe is part of the system or (b) that the user will find it
difficult to operate dselect.
(a) is likely to happen when the user is overwhelmed by dselect and
just wants to `quit out'. This will probably be fairly rare (compared
to the people who skip the [S]elect stage altogether - at some point
I'll add a check for this). However, when it does happen the user
will probably be sufficiently clueless to read any of the FAQs and so
forth and complain that Debian lacks the program <foo>, or report it
as a bug. We'll have to spend extra time explaining to them, and on
public relations.
(b) is worse. dselect can be quite daunting, and it is IMO important
to give people an easy route to doing a reasonably-full `standard'
installation. The `consequences' are only user unhappiness and
complaints, but they may be much more widespread.
So, I think that on balance this is the right choice.
> On Tue, 19 Sep 95 22:06 BST, Ian Jackson <iwj10@cus.cam.ac.uk> said:
> > I'll arrange for the introductory help screen to appear on entry to
> > the package list, and I've changed it to say that packages will be
> > selected by default and how to override this.
>
> [...]
> > This behaviour will be configurable.
>
> Sounds good. Some sort of Novice/Expert mode would be nice.
It sounds like a nice idea, doesn't it ? However, it turns out that I
can't think of many user interface decisions that would sensibly be
changed by such a choice. I do intend to make much of the user
interface more configurable than it is - right up to the point of
having dselect completely ignore dependencies and conflicts, if that's
what you want.
> [re the `q' key, and Return]
I was rather unclear in my last message. The situation was that `q'
was interpreted as `confirm'. That operation has now (0.93.76) been
rebound to Enter.
> So will "q" then mean that the packages will be returned to their
> previous state?
No, `q' now just beeps. I thought that `abort all changes' was too
dangerous a thing to put on an obvious key like `q'. In order to
abort your changes you have to say capital `X'; this is listed on
the keybindings screen, and is mentioned specifically in the
introduction to conflict/dependency resolution lists.
> I'm afraid I don't understand your objection. Why would not seeing
> pages and pages of "skipping package xxx" be confusing? Eliminating
> these would actually make it less confusing because it would be harder
> to miss meaningful messages about packages that ARE being installed.
> In any case, this can probably be resolved after the release.
The package selection scheme has plenty of scope for people shooting
themselves in the foot. Having a dselect-invoked dpkg silently ignore
deselected packages would make it hard for people to understand why
the system was not installing a particular file.
The messages also provide a progress indication, in case dpkg is
searching large areas of deselect packages. This isn't a problem on
fast machines, but on slow ones it can be (I can simulate this by
compiling dpkg &c for myself with the full debugging turned on (-:).
Meaningful messages that the user *must* see should always have a
prompt to confirm. They should also be rare. Most messages should
simply be reassuring.
Ian.
Reply to: