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

Re: improvements



When Kendrick Myatt, et. al. wrote, I replied:
> Somebody wrote:
> >> communications  non-networking communications
> >> documentation   all documentation
> >> development     as is currently
> >> games           all games
> >> graphics        anything which creates, massages, transforms graphics
> >> misc            catch all- math, electronics, hamradio, "misc", etc.
> >> networking      any networking functions- mail, news, utilities, etc.
> >> printing        anything dealing with printing- TEX, lout, etc.
> >> system          admin, base, shells, X windows, etc.

IMHO X deserves a heading of its own. Perhaps TEX/Ghost*/(the package
that handles MIME)/etc. need an area as they cut across printer/X.

> #################
>         I am really in favor of this as well, if it would be possible.  The
> way it is laid out now is more than a little muddy.  Right now I seem to be
> getting the emacs package, which I do not want.  I was thinking the
> interface of the packages would be more like above.   It is an *awful* lot
> to scroll through once you get the list of packages, IMHO, and it was easy
> for me to get "lost."
>         Mainly breaking it up a little more into categories would have let
> me build the system I want better.  Like, I could go into a Utilities menu
> and choose editors and then choose vi and pico, but not emacs.  Then go back
> and under networking go to mail and get pine, then back up and go to news

There needs to be an automated way to find specific packages which are
at leaf positions without knowing the path from the top. I often try
to surmise what the purpose of a package whose name i've overheard by
looking at the source modules names (or by grepping the source, itself).
I might not have a clue as to what its top-level entry is.

> and get tin, but not INN since I just want to read from another server, not
> host news.
>         I know, it's easy for me to suggest all this when someone else would
> have to do the work :)  But, it's just some ideas from a first-time Debian

I'd build a perl DB to do this and other keen things, but I lack
experience with the internals of dselect and organisation of the
current dependancy info (and probably some other things I haven't
anticipated) and I don't know anything about dpkg (I think dpkg is
the what dselect uses as prinitives???).

> user.  Mainly I expected the interface to make things LESS confusing instead
> of MORE.  I really like the way Slackware does their install (& that's about
> it) and I like being able to manipulate packages like I can in Solaris.  I
> think that Debian is almost a "best of both worlds" system, but can still
> use some work, especially in the initial setup area.  Example, why do I seem
> to be getting the British ispell dictonary!!! *sigh*  Little things like that :)
>         I still think it's way cool all in all :)  I may re-do it from
> scratch just for the experience :)
> 
> Regards,
> Kendrick
I just wish my selections were stickier.  And a mode that simply
includes required packages, rather than getting user confirmation on a
per-package basis would be appreciated. The "What you need to dselect
using ftp" should be the minimum and included automatically (if you want
a more minimalist package, strip it yourself. It all begins to sound
like a more formal DB may be desirable.

I remain, Ralph		rjw@nac.net


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: