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


Amos Shapira <amos@dsi.co.il> wrote on Tue, 15 Apr 1997:
> What I'd like to see is a way for the user to individuallt decide
> whether he/she wants to install certain "sections" from a package.
> This again merges into a previous point I raised of combining a few
> related packages into one (e.g. mgetty-{docs,fax,voice,}) and let the
> user pick from inside it.

Alternatively, a package could have several packages inside it, nested
to arbitrary levels.  You could pick all of a package, or some of its
subpackages, or some of their subpackages,...

Before making massive changes in dpkg/dselect, I would like to point
out that one of the difficulties naive users have with the existing
tools is their lack of documentation.  Some existing features are
not documented anywhere I know, and yet have been useful to me.
The new tool must have its documentation from a very early stage in
its availability.

That said, I often get complaints about some of the features (or
characteristics) of dselect:

(1)  Missing dependencies should not cause the user to leave the
     select screen until all selections have been made.
(2)  The organisation of selectable packages has been improved,
     but it is still too large.
(3)  Dselect's need to go through all available packages in order
     to install one package is irritating; for this reason many
     users prefer to use dpkg directly.
(4)  Many of my users have got their systems into states in which
     dselect hangs or is unable to deal with things.  It is usually
     almost impossible to reproduce this, since we don't know what
     they selected or in what order.
     (a)  It would be nice to have some sort of temporary audit trail
          for dselect.
     (b)  It would be nice to be able to fix problems automatically;
          a diagnostic tool could report what is actually wrong and
          offer to fix it.
(5)  How many systems I have fixed recently on which (an older) dpkg
     failed to work because it couldn't understand an updated
     /var/lib/dpkg/available file.  Many of these also had problems
     with the updated version of perl.  In these cases I installed
     ld.so, dpkg, libc, and perl manually.  This sort of thing
     should be able to be handled by the software.

I hope some of the people in this group will look at the strengths
and weaknesses of existing commercial systems, from which we might
be able to get a lot of good and bad ideas.  Among these systems
are HP's update/updist and swcopy/swinstall (SD-UX) systems, SGI's
inst, etc.  In some cases one needs to be very familiar with these
tools to appreciate what is good and bad about them.

     -- Owen

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: