Re: A proposal to improve dselect
On Sun, 12 Jan 1997, Orn E. Hansen wrote: >You're really losing the point here... what is in your mind, an EASY > installation? A brain dead program, that does all your thinking for you? Come on!!! All I was saying was that it is not CONSISTENT of dselect to start a XF86Setup during the config phase if installed, but no xf86config, not even a word about it. Not good for new users. If only the documentation was good enough so you could read it there but it's out of date. I was merely pointing it out. > Look at Windows... and all the users running it, with its "idiot proof" > user interface? You want to make a Debian shot at where Microsoft is failing I stopped reading here, and I hope I will not receive any further replies from you. // Jonas <[EMAIL PROTECTED]> [2:201/262.37] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> From: "Orn E. Hansen" <[EMAIL PROTECTED]> > Look at Windows... and all the users running it, with its "idiot proof"= > > user interface? You want to make a Debian shot at where Microsoft is fail= > ing > so miserably? All you will ever accomplish is a big bunch of helpless > users, that can't even figure out by themselves to re-start a program whe= > n it = > > gets stuck. Wrong. The problem with Windows (well, the problem _I_ have with it) is not that it tries to magically do everything without user intervention. It's that there's no fricking documentation to know how it works to fix it when it doesn't get things right. > The installation should be as complex as it needs be, to be able to tak= > e > care of all possible needs of the system, with the systems cababilities i= > n > mind. But CONTEXT RELATIVE... which is not the same as EASY. This means= > if > you are new to the system, you have to Read The Fuckin' Manual, but if yo= But where is that Fine manual? Installation instructions need to point to it. Daniel -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> From: Pete Templin <[EMAIL PROTECTED]> > > > On Sat, 11 Jan 1997, Jonas Bofjall wrote: > > > No, this is wrong. A new user should not have to read long documents prior > > to installation. The configure scripts which runs directly after the > > installation should make reading docs unnecessary. > > I disagree. You should understand what you are doing. If you don't even You shouldn't have to understand so much. (Obviously, the system can't do everything, but ...) > want to know what is going and how you are to use it, what is the point of > having it? Bragging to your friends? No. Maybe the point is to get the system installed and do some useful work with it. What's useful to someone might be learning something other than system installation and configuration. ... > The installation process is not (necessarily) the place to learn about > packages. Dselect in particular does not have room (unless you've got How not? You are installing a system by working with packages. Therefore, don't you need to know something (no, hopefully not everything) about packages right then or before? > some incredible montior and a very long xterm) to give full installation, > configuration, and operation instructions before or during installation. > If it did, how would publishers like O'Reilly and Associates be in > business? > > This is the real world. We as humans may have to read a bit and learn a > bit to use a bit of our toys. Remember, it's JUST a computer. ...loaded up with software written--and packaged--by people. That packaging should address documentation a bit more. For example, when I finished the Debian installing-from-diskettes instructions, it seemed like something was missing. "Okay, what do I do next?" (It told how to install whatever you wanted with dselect, etc., but didn't remind where to go to find the configuration instructions for various things.) That installation documentation document should at least point users to /usr/doc. Daniel -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> From: [EMAIL PROTECTED] (John Hasler) > No, this is wrong. The new user should be provided with copious > documentation and be admonished to print it out and read it. ^^ don't forget _organized_ -- or they'll never find the right information Daniel -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Sun, 12 Jan 1997, Orn E. Hansen wrote: > The installation should be as complex as it needs be, to be able to take > care of all possible needs of the system, with the systems cababilities in > mind. But CONTEXT RELATIVE... which is not the same as EASY. This means if > you are new to the system, you have to Read The Fuckin' Manual, but if you that's right > are experienced computer guru, does this mean I am an experienced computer guru? > you should be able to find your way through > with minimum effort. > > The user, her/himself is far better off by going through an initial phase, > where she/he will get intimite with the system. It will save the user a > lot of money/time and frustration later on. That's what I tell people too. --- signature file gotta put something here --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> "Pete" == Pete Templin <[EMAIL PROTECTED]> writes: Pete> On Sat, 11 Jan 1997, Jonas Bofjall wrote: >> No, this is wrong. A new user should not have to read long >> documents prior to installation. The configure scripts which runs >> directly after the installation should make reading docs >> unnecessary. Pete> I disagree. You should understand what you are doing. If you Pete> don't even want to know what is going and how you are to use it, Pete> what is the point of having it? Bragging to your friends? I think both of you have valid points. It is clear that there is a compromise to be reached. The installation scripts should ``remind'' user of important features while some document reading are necessary before the extensive use of a package. -- Billy C.-M. Chow <[EMAIL PROTECTED]> Department of Systems Engineering The Chinese University of Hong Kong -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Jona Bofjall <[EMAIL PROTECTED]> wrote: > > No! Installation should be as easy as possible. Our goal should be to make > it so easy that no one has to look in the manual. And we're not far from > there. I gave my two friends rex and told them to install it, after having > saying good things about it for several months. Neither of them have used > any unix before. Both made very few mistakes. I see this as a success for > Debian, BUT, both made the mistake i posted about. So making this clearer > would make installation easier, at least for some people. > Easier installation is Good. > You're really losing the point here... what is in your mind, an EASY installation? A brain dead program, that does all your thinking for you? You want your Linux box to be like your C64... just power on and wait for the "Ready." prompt? Look at Windows... and all the users running it, with its "idiot proof" user interface? You want to make a Debian shot at where Microsoft is failing so miserably? All you will ever accomplish is a big bunch of helpless users, that can't even figure out by themselves to re-start a program when it gets stuck. The installation should be as complex as it needs be, to be able to take care of all possible needs of the system, with the systems cababilities in mind. But CONTEXT RELATIVE... which is not the same as EASY. This means if you are new to the system, you have to Read The Fuckin' Manual, but if you are experienced computer guru, you should be able to find your way through with minimum effort. The user, her/himself is far better off by going through an initial phase, where she/he will get intimite with the system. It will save the user a lot of money/time and frustration later on. -- Ørn Einar Hansen [EMAIL PROTECTED] [EMAIL PROTECTED] fax; +46 035 217194 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Sat, 11 Jan 1997, Pete Templin wrote: > > No, this is wrong. A new user should not have to read long documents prior > > I disagree. You should understand what you are doing. If you don't even > want to know what is going and how you are to use it, what is the point of > having it? Bragging to your friends? I guess you people are right about that of course any user should follow instructions. But that is no reason why installation is harder than it has to be. Then why do we have dselect in the first place? Just supply dpkg and a complete manual and we would not have any problems? Right? No! Installation should be as easy as possible. Our goal should be to make it so easy that no one has to look in the manual. And we're not far from there. I gave my two friends rex and told them to install it, after having saying good things about it for several months. Neither of them have used any unix before. Both made very few mistakes. I see this as a success for Debian, BUT, both made the mistake i posted about. So making this clearer would make installation easier, at least for some people. Easier installation is Good. // Jonas <[EMAIL PROTECTED]> [2:201/262.37] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> > The real question is: "What key does dselect use for repeat searches?" > > rather than "What key should it be?". > > It is just pure / WITHOUT any pattern. It is exactly the same in "more". "/" always seems to take me to the first package matching that description. "\" is the repeat key, Rick points out. hamish -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Sat, 11 Jan 1997, Jonas Bofjall wrote: > No, this is wrong. A new user should not have to read long documents prior > to installation. The configure scripts which runs directly after the > installation should make reading docs unnecessary. I disagree. You should understand what you are doing. If you don't even want to know what is going and how you are to use it, what is the point of having it? Bragging to your friends? > My totally-newbie friends were both given rex of my HD. They both called > me after installation and asked how to get X started. Neither had > configured X in any way. How are they supposed to know? > The post-install configure script should take care of it. The installation process is not (necessarily) the place to learn about packages. Dselect in particular does not have room (unless you've got some incredible montior and a very long xterm) to give full installation, configuration, and operation instructions before or during installation. If it did, how would publishers like O'Reilly and Associates be in business? This is the real world. We as humans may have to read a bit and learn a bit to use a bit of our toys. Remember, it's JUST a computer. --Pete ___ Peter J. Templin, Jr. Client Services Analyst Computer & Communication Services tel: (717) 524-1590 Bucknell University [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Fri, 10 Jan 1997, Igor Grobman wrote: > I am no expert either, but pushing / and entering the search string does > take you to a different package IF it exists. Otherwise, it just takes > you back to the one package that matches the string. > Good! That is what most would expect. If you don't want to type the search string in again the \ will find the next occurance. The real key of interest here should be the ? key. This will lead you to answers to questions like this without requiring any email. (at least in some cases) Luck, Dwarf -- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 If you don't see what you want, just ask -- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Jonas Bofjall writes: > No, this is wrong. A new user should not have to read long documents > prior to installation. No, this is wrong. The new user should be provided with copious documentation and be admonished to print it out and read it. > The configure scripts which runs directly after the installation should > make reading docs unnecessary. Every effort should be made in the design of these scripts to make reading the docs unnecessary, but, despite our best efforts, this will sometimes fail. Then the above mentioned docs will save the day. John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Thu, 9 Jan 1997, Chow Chi-Ming wrote: > Then I don't think it can be considered a bug per se. If XF86Setup is Neither do I. > not on your system, you are not expected to run it. You must come > across XF86Setup from some other documents and from the same source Yes, but as a totally new user, how am I expected to know. I propose any of the following solutions: 1) Put some notice in the installation process, making the user aware that he/she *must* install vga16 if he/she is a newbie. Maybe in the configuration script (sorry, but if you wish to configure this you need to install vga16). 2) Create some sort of dependencies to force the inexperienced user to install vga16. 3) Run xf86config instead of XF86Setup during configuration, if the XF86Setup isn't available. There should also be a notice like "you'll get a much nicer graphical setup if you install vga16". > serious one. How would you know that you can use XF86Setup and that > vga16 has to be installed without consulting docs. The same applies No, this is wrong. A new user should not have to read long documents prior to installation. The configure scripts which runs directly after the installation should make reading docs unnecessary. My totally-newbie friends were both given rex of my HD. They both called me after installation and asked how to get X started. Neither had configured X in any way. How are they supposed to know? The post-install configure script should take care of it. > What we can do, I think, in Debian is that in each of the post-install > scripts of xservers (except vga16 obviously), check the existance of > XF86Setup. If it is not found, offer an option to users to install > vga16 and get the nice XF86Setup ``or'' start xf86config if the user A very good idea! But it the user hasn't got XF86Setup he should be told so, and told what it is and how to install it. // Jonas <[EMAIL PROTECTED]> [2:201/262.37] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Thu, 9 Jan 1997, Dale Scheetz wrote:
> On Wed, 8 Jan 1997, Karl M. Hegbloom wrote:
>
> > > "Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:
> >
> > Hamish> Pressing / and entering the same search just takes you
> > Hamish> back to the first result again. This is counter-intuitive
> > Hamish> for users of vi, less etc. Lynx uses "n" to repeat a
> > Hamish> search but dselect doesn't use that either.
> >
> > I thought the same thing. It should work like 'less' does. And have
> > {C-s} and {C-M-s} incremental searching like Emacsen do as well,
> > perhaps.
> >
> This begins to look like a religeous discussion ;-)
>
> The real question is: "What key does dselect use for repeat searches?"
> rather than "What key should it be?".
>
> I'm not an expert on dselect. I use dpkg almost exclusively to do my
> incremental upgrades. I don't know if there is such a key, or not, but
> it's clear it isn't documented very well if there is one. If there isn't
> the bug is in the software instead of the docs (or including the docs).
> Do we have an expert out there who can answer this question?
I am no expert either, but pushing / and entering the search string does
take you to a different package IF it exists. Otherwise, it just takes
you back to the one package that matches the string.
__
Proudly running Debian Linux! Linux vs. Windows is a no-Win situation
Igor Grobman [EMAIL PROTECTED]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Dale Scheetz wrote: > The real question is: "What key does dselect use for repeat searches?" > rather than "What key should it be?". > > I'm not an expert on dselect. I use dpkg almost exclusively to do my > incremental upgrades. I don't know if there is such a key, or not, but > it's clear it isn't documented very well if there is one. If there isn't > the bug is in the software instead of the docs (or including the docs). > Do we have an expert out there who can answer this question? By now everyone has seen my post saying that it's "\". I'm surprised that people don't think to press "?" for help as shown at the top right corner of dselect, then press "k" for keystrokes. Perhaps the only way to make everyone happy is to have dselect read in a ".dselectrc" file with key assignments, like bash does. Of course, this capability would also have to dynamically update the kestroke help file... Anyway, here is the keystroke help for the "?k" challenged: Help: Keystrokes Motion keys: Next/Previous, Top/End, Up/Down, Backwards/Forwards: n, Down-arrow, j p, Up-arrow, k move highlight N, Page-down, Space P, Page-up, Backspace scroll list by 1 page ^n^p scroll list by 1 line t, Home e, End jump to top/end of list u d scroll info by 1 page ^u^d scroll info by 1 line B, Left-arrow F, Right-arrow pan display by 1/3 screen ^b^f pan display by 1 character Mark packages for later processing: +, Insert install or upgrade =, H hold in present state -, Delete remove :, G unhold: upgrade or leave uninstalled _ remove & purge config Miscellaneous: Quit, exit, overwrite (note capitals!): ?, F1 request help (also Help) Return Confirm, quit (check dependencies) i, I toggle/cycle info displays Q Confirm, quit (override dep.s) o, O cycle through sort options X, Esc eXit, abandoning any changes madev, V change status display opts R Revert to state before this list ^l redraw display U set all to sUggested state / search (Return to cancel) D set all to Directly requested state\ repeat last search -- ...RickM... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Fri, 10 Jan 1997, Hamish Moffatt wrote: > Dale writes: > > I'm not an expert on dselect. I use dpkg almost exclusively to do my > > incremental upgrades. I don't know if there is such a key, or not, but > > it's clear it isn't documented very well if there is one. If there isn't > > the bug is in the software instead of the docs (or including the docs). > > Yell at me for saying this if you will, but what docs? I'm sure they > exist, but I've never read them. Installation, through dselect, > should be simple enough that you do not need documentation > to do it. I think the installation documentation that exists > is fair enough and required (I admit I read it, disregarded the advice > regarding switching off APM, and promptly had to start over :-), > but dselect, imho, needs to be intuitive enough for documentation > to be unrequired. I never opened the Windows95 manual, nor > any documentation on Slackware's pkgtool, if indeed there is any ... > You are certainly correct about the sparce nature of the current documentation. As I am not well versed in the product, and have a full plate, I'm not the one to do this. The problem is, there isn't anyone in a position to do something about it. Anyone who is interested in contributing to the project, but doesn't think they are enough of a programmer to do anything useful, can provide great help for new users by studying dselect and producing a users document from what they learn. Luck, Dwarf -- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 If you don't see what you want, just ask -- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Fri, 10 Jan 1997, Gertjan Klein wrote: > In article <[EMAIL PROTECTED]>, > Philippe Troin <[EMAIL PROTECTED]> wrote: > > > Not a bug. What you describe is pre-dependencies. It's a bit too long > > to explain here, but you can find all the details in the Debian > > policy manual. > > Dpkg does the work right... so far. > > Interesting. I looked in /usr/doc/debian, and found no policy manual. > I finally found a policy.html _directory_ in /usr/doc/dpkg; I read all > the files in it and couldn't find "all the details" there... But perhaps > there already is a misunderstanding, as you're talking about dpkg, and I > was talking about dselect. (Or maybe I don't understand the interaction > between the two). Dselect knows the dependancies between the packages it > has to install, and should should present them to dpkg in the right > order. Depends doesn't mean that the package most be install first - that's what pre-depends are for - it only means that's this package must be install with the other one. Also, the package are supposed to be install easily without pre-dependencies. According to the policy manual, Pre-depends must *not* be use unless is it vital for the installation of the package. If you encounter this kind of bugs, registered it to Debian and the maintainer will had the Pre-Depends to its control file or, better way, correct it's installation process to not Pre-Depends on any package other then the base or Essential. The reason why this should be avoid is because of the risk to see a vicious circle of pre-dependencies. Dselect are still just a wrapper around dpkg and the methods script (as described in the programmer manual). Must of the scripts (if not all) who install the package use dpkg --recursive to install the package. It's the simpler way of doing this. If you want, you can try to do it more efficiently by parsing only already selected packages (removing all the "skipping deselected package" - do 'dpkg --help | more' to find how you can get a list of selected package) and/or adding installation of dependencies before the depending package (watch out for package who depends on each other!). If you're script work well, you can make a package with or submit it to Ian for inclusion to the standard dselect distribution. Don't give up and sorry for the long mail but I think this can be of interest for the users (just looking for the size of this thread!). Ciao! Fab. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Dale Scheetz wrote:
>
> On Wed, 8 Jan 1997, Karl M. Hegbloom wrote:
>
> > > "Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:
> >
> > Hamish> Pressing / and entering the same search just takes you
> > Hamish> back to the first result again. This is counter-intuitive
> > Hamish> for users of vi, less etc. Lynx uses "n" to repeat a
> > Hamish> search but dselect doesn't use that either.
> >
> > I thought the same thing. It should work like 'less' does. And have
> > {C-s} and {C-M-s} incremental searching like Emacsen do as well,
> > perhaps.
> >
> This begins to look like a religeous discussion ;-)
>
> The real question is: "What key does dselect use for repeat searches?"
> rather than "What key should it be?".
>
> I'm not an expert on dselect. I use dpkg almost exclusively to do my
> incremental upgrades. I don't know if there is such a key, or not, but
> it's clear it isn't documented very well if there is one. If there isn't
> the bug is in the software instead of the docs (or including the docs).
> Do we have an expert out there who can answer this question?
>
It is just pure / WITHOUT any pattern. It is exactly the same in "more".
Pawel.
--
Pawel T. JochymInstitute of Nuclear Physics
e-mail: [EMAIL PROTECTED]Cracow, Poland
tel. 37-02-22 ext. 269
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> On Wed, 8 Jan 1997, Hamish Moffatt wrote: > > I don't use emacs, but to me dselect seems to be already too > > emacs-oriented. For example, searching for a package is done with /, > > but how do you repeat the search? I haven't studied the help > > in much detail, but for me the answer is "I don't know" presently. > > It's "\". Ahh, of course. > "/" isn't a special key in emacs. Lotus 1-2-3 maybe. And vi, and less, and even lynx. The former two both use a single / (with no arguments) to repeat the previous search. Suggestion, then: dselect should implement more vi-isms if any, in search of increased intuition. > > (vi fan) > Oh, well. In that case, click here: o > ;-) Very droll. :-) Hamish (using elm on a character terminal, over modem from Telix on DOS, as it happens. AND a 1-2-3 fan :-) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> > > "Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes: > > Hamish> We should certainly not force a particular editor down > > Hamish> anyone's throat, especially emacs :-) > > > > I think it is pretty safe to assume that many Linux people use BASH. > > >From the bash manpage > > > >given. By default, the line editing commands are similar > >to those of emacs. A vi-style line editing interface is > >also available. > > I don't remember seeing complains saying bash should certainly not > > force emacs-bindings down someone's throat. Two points. As far as I've noticed, bash (or specifically, readline) does not use emacs keys all that much. Yes, I certainly prefer arrow keys to vi's hjkl, but other dselect keys (especially the search interface) are very non-intuitive to me. Hence, while bash is using emacs bindings, it isn't to a very large-scale degree, or at least it doesn't adversely affect me. Secondly, I use tcsh for my interactive non-root accounts anyway. I've used tcsh with vi bindings and it's a PITA. hamish -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
In article <[EMAIL PROTECTED]>, Philippe Troin <[EMAIL PROTECTED]> wrote: > On Wed, 08 Jan 1997 15:42:27 +0100 Gertjan Klein ([EMAIL PROTECTED]) > wrote: >> One of my most serious criticisms is the fact that in spite of the >> dependencies being known, packages aren't installed in the right order. >> If package 1 depends on package 2, then package 2 *must* be installed >> *first*. This isn't done; I consider this a bug, that should be >> reported. > Not a bug. What you describe is pre-dependencies. It's a bit too long > to explain here, but you can find all the details in the Debian > policy manual. > Dpkg does the work right... so far. Interesting. I looked in /usr/doc/debian, and found no policy manual. I finally found a policy.html _directory_ in /usr/doc/dpkg; I read all the files in it and couldn't find "all the details" there... But perhaps there already is a misunderstanding, as you're talking about dpkg, and I was talking about dselect. (Or maybe I don't understand the interaction between the two). Dselect knows the dependancies between the packages it has to install, and should should present them to dpkg in the right order. I don't want to start word games here, but in my opinion a bug is an unintended or undesired feature. I can hardly imagine the debian developers finding it desirable to present an unexpecting installer with lots of error messages about dependancies, but if they do, I urge them to reconsider this point of view. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Dale writes: > I'm not an expert on dselect. I use dpkg almost exclusively to do my > incremental upgrades. I don't know if there is such a key, or not, but > it's clear it isn't documented very well if there is one. If there isn't > the bug is in the software instead of the docs (or including the docs). Yell at me for saying this if you will, but what docs? I'm sure they exist, but I've never read them. Installation, through dselect, should be simple enough that you do not need documentation to do it. I think the installation documentation that exists is fair enough and required (I admit I read it, disregarded the advice regarding switching off APM, and promptly had to start over :-), but dselect, imho, needs to be intuitive enough for documentation to be unrequired. I never opened the Windows95 manual, nor any documentation on Slackware's pkgtool, if indeed there is any ... hamish -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Thu, 9 Jan 1997, Ralph Winslow wrote: > When Chow Chi-Ming wrote, I replied: > > This seems easily addressed by honoring the Users' EDITOR environment > variable setting, so why not? Its not always set. Richard G. Roberto [EMAIL PROTECTED] 011-81-3-3437-7967 - Tokyo, Japan -- *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Thu, 9 Jan 1997, Ralph Winslow wrote: > This seems easily addressed by honoring the Users' EDITOR environment > variable setting, so why not? This may already be implemented, so forgive me if I haven't researched dselect enough: how about using a config file where we can remap all the keystrokes? My first thought when running dselect was, "WTF?" My second was, "How do I quit? The command line couldn't possibly be as confusing." I'm not knocking the program; it's really cool. I just can't handle the user interface. Maybe some hacker can rip out the base of dselect and turn it into a library (libdebian?), so that people can easily design programs with the functionality of dselect, but with a custom UI. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Wed, 8 Jan 1997, Karl M. Hegbloom wrote:
> > "Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:
>
> Hamish> Pressing / and entering the same search just takes you
> Hamish> back to the first result again. This is counter-intuitive
> Hamish> for users of vi, less etc. Lynx uses "n" to repeat a
> Hamish> search but dselect doesn't use that either.
>
> I thought the same thing. It should work like 'less' does. And have
> {C-s} and {C-M-s} incremental searching like Emacsen do as well,
> perhaps.
>
This begins to look like a religeous discussion ;-)
The real question is: "What key does dselect use for repeat searches?"
rather than "What key should it be?".
I'm not an expert on dselect. I use dpkg almost exclusively to do my
incremental upgrades. I don't know if there is such a key, or not, but
it's clear it isn't documented very well if there is one. If there isn't
the bug is in the software instead of the docs (or including the docs).
Do we have an expert out there who can answer this question?
Luck,
Dwarf
--
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308
If you don't see what you want, just ask --
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
IMO dselect is a wonderful tool and Debian would be sunk without it. We all owe a great deal to Ian for his work. The problem is that the learning curve for new users is a bit steep. The words _brick_wall_ have been mentioned. On initial install could dselect be run in the background so that newbies are shielded from the nuts and bolts? Or, to be more accurate, so that they are not allowed to fiddle with the defaults. This would upgrade things one more level from the base package. The user will have a working system and can then learn about dselect as time permits. I also think the idea of having dselect install different flavours of Linux for differing needs by getting it to work with a list has merit, though the primary need is one for newbies. If dselect had this ability different groups could then roll their own. As I am the chap who landed the job of documenting dselect for 1.2 install, I would like email from those who followed my recommendation to stick with the defaults. How much difficulty did you then have? Other constructive comments are also welcome. Lindsay -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
When Chow Chi-Ming wrote, I replied: This seems easily addressed by honoring the Users' EDITOR environment variable setting, so why not? > > > "Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes: > > Hamish> We should certainly not force a particular editor down > Hamish> anyone's throat, especially emacs :-) > > I think it is pretty safe to assume that many Linux people use BASH. > >From the bash manpage > > [...] > READLINE >This is the library that handles reading input when using >an interactive shell, unless the -nolineediting option is >given. By default, the line editing commands are similar >to those of emacs. A vi-style line editing interface is >also available. > [...] > > I don't remember seeing complains saying bash should certainly not > force emacs-bindings down someone's throat. > > IMHO, having some consistencies across applications that involve > editing is good. Having said that, are key bindings of an editor > appropriate for dselect is another question. > > regards, > > -- > Billy C.-M. Chow <[EMAIL PROTECTED]> > Department of Systems Engineering > The Chinese University of Hong Kong > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Wed, 8 Jan 1997, Jonas Bofjall wrote: > About what could be made easier in Debian: > I gave Debian 1.2 to two people who has little or no experience with > Linux. They both made the same mistake, not installing the 16 color X > server. This should be clarified, that you will need it because it > provides things essential to configuring X. I have a suggestion for the Debian development team. Perhaps, we could (start to) include some info on why certain packages depend on others. That way when dselect complains about a dependency problem the user would be informed on the reasons behind the dependencies. I know this probably wouldn't be a trivial thing to implement, so I was thinking maybe support could be built into the next dselect for it. That way package maintainers can take their time upgrading the packages to support this feature. This then would have solved the 16 colour X server problem above, by telling the user that VGA16 was needed to configure their Xserver. just my 2cents, mike... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> "Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes: Hamish> We should certainly not force a particular editor down Hamish> anyone's throat, especially emacs :-) I think it is pretty safe to assume that many Linux people use BASH. >From the bash manpage [...] READLINE This is the library that handles reading input when using an interactive shell, unless the -nolineediting option is given. By default, the line editing commands are similar to those of emacs. A vi-style line editing interface is also available. [...] I don't remember seeing complains saying bash should certainly not force emacs-bindings down someone's throat. IMHO, having some consistencies across applications that involve editing is good. Having said that, are key bindings of an editor appropriate for dselect is another question. regards, -- Billy C.-M. Chow <[EMAIL PROTECTED]> Department of Systems Engineering The Chinese University of Hong Kong -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Debian for regular folk (was: A proposal to improve dselect)
On Wed, 8 Jan 1997, Ami Ganguli wrote: > Michael Stutz wrote: > > I am starting a project now that I've > > been thinking about for some time: making a custom Debian "distribution" > > geared toward writers, artists and other creative types who don't have much > > knowledge of Linux to start with. > I think this is a fantastic idea! But I'm not sure about the particular > audience you mention (except maybe for 'Net access). You need to identify > user groups that would be well served by what's available (HAM operators?). Yes, that's mentioned in 15.3 in the FAQ. As for writers, I believe that anything on the market for wintel cannot compare to the tools I have available with Debian/GNU Linux (emacs, TeX, rcs, ispell, bash, perl, etc). Not only can I do serious text editing, but I can produce _typeset_ copy. Yes, there is TeX for windows but it's the combination of tools I have that's so powerful. Graphics is the same, with The GIMP, pbmplus, ghostview, xpaint, etc. And of course net access. And even all the tools a small business or art/craft venture needs (sc, bc, xcalc, xfig, etc). So I would think that a custom distribution and the appropriate manuals could be excellent for others with these interests, except it would be minus the initial work of pulling it all together, getting everything to work, figuring out best practices, etc. > I like the 'sponsor' idea a lot - but the system should be developed to a > point where the administration is virtually non-existent (by current > standards) > or this could be hellish. The role of the sponsor should be limited to > answering > questions except in extreme cases. Yeah, this is definitely 'idea stage' material here. But I do believe that we're at that point (with Linux) that if we can concieve of something, we can make it happen. m Michael Stutz | DESIGN SCIENCE LABS http://dsl.org/m | Hypermedia, Internet, Linux/GNU bumper stickers,indie rock,rants | Linux: http://dsl.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> From: "Richard Morin" <[EMAIL PROTECTED]> ... > Now really, how much can a complete novice really do with a new Linux > machine. It takes an investment of time, energy, and interest to > learn even the simplest of tasks, but once you know them ;-) ^^ ...it still doesn't help because you install a new distribution which requires learning an entirely different set of customizations, which you can't figure out because there never was decent documentation to really learn how things worked with trying every little option yourself! I'm not complaining about Debian, or its being different--I'm complaining about the apparent general Unix philosophy of never really providing decent documentation...well...at least for all the things I happen to run into (where it's weak on critical details and on orientation to how things fit together). (What's my current frustration? I can't edit anything efficently in emacs because I still haven't been able to find sufficient documentation to set up my keyboard under X. This isn't a Debian problem (as far as I know). For example, the X man. page that documents XkbOptions doesn't say what legal values for the option are. So how on earth can one know what option values to use?) > I think it is more important to help complete novices learn a little > about what is possible with their new O/S and let them investigate > what _they_ want to. Yeah it may take some time to get a fully > functional system, but that is how everyone else here did it, right? That is no excuse (to avoid trying to do better, for anyone who wants Debian or Linux to be used more widely). Remember, the users might want do something other than Unix system admini- stration. For example, the main reason I just installed Debian was to upgrade my old Slackware 2.1 system to ELF and a modern kernel, and that was to be able to get Java tools and learn it. My goal of upgrading was to be able to do cer- tain other things, not to learn more about Unix/Linux administration. Yes, it was worth the time it took to learn dselect, because I'll keep using that as I download, install, and remove things. And, yes, I have learned a little more about various other things, but the hours I've spend trying to get X and other problems fixed and out of the way are a different story. And I still don't know any Java. Remember, I'm not saying Debian is bad, or free software is bad, just that whoever wants more non-hackers (that is, not-so-experienced or non-so- technical users) to use it better keep user needs in mind. Daniel -- Daniel S. Barclay Compass Design Automation, Inc. [EMAIL PROTECTED] Suite 100, 5457 Twin Knolls Rd. Columbia, MD 21045 USA -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
[Fun. The spamfilter rejected my email. Musta forgot to register my silas account.] : To the other newbies out there, this mailing list somehow ends up : archived as a newsgroup. I've found lots of help by searching : problems at : http://www.dejanews.com/ There's a mail-to-news gateway, I think at yggdrasil(sp?). It's supposed to be moderated, and the moderator's address is - you guessed it - [EMAIL PROTECTED] That way, posts to the newsgroup (should) reach the mailing list, and vice versa. Just FWIW. The newsgroup is linux.debian.user. -- "Okay, I've created my \etc directory. What files do I put into it?" Lusers. Can't live with 'em, can't shoot 'em... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Wed, 8 Jan 1997, Philippe Troin wrote: > > On Wed, 08 Jan 1997 15:42:27 +0100 Gertjan Klein ([EMAIL PROTECTED]) > wrote: > > > One of my most serious criticisms is the fact that in spite of the > > dependencies being known, packages aren't installed in the right order. > > If package 1 depends on package 2, then package 2 *must* be installed > > *first*. This isn't done; I consider this a bug, that should be > > reported. > > Not a bug. What you describe is pre-dependencies. It's a bit too long > to explain here, but you can find all the details in the Debian > policy manual. > Dpkg does the work right... so far. > > Phil. I beg to differ, but dpkg has not been doing the work right on my system. Indeed if you read the install reports being posted, you'll see that the "fix" for many instllation problems is to reinstall the broken package as its depended upon package was probably installed after it. gcc, perl, some parts of the libc stuff (don't remember which or what) gagged on me. In dselect it was too easy to fix to care about it (despite its bad wrap about the interface, dselect really does kick ass), so I don't have any specifics. I think Gertjan is right. Pre-dependencies are only for packages that rely on a fully functional (i.e. unpacked and configured) package in order to install. Dependencies on packages that are required for the package to run (but not required for installation) should not be pre-depended upon. These are just standard depends. Although largely this works out OK, I have seen some problems on my system with it and have certainly seen enough reports here to agree with Gertjan. I think that Dale and someone else (maybe Manoj?) are working on dselect back end type stuff that addresses this ordering issue. That would take the burden off of dpkg to do this when the new back end is in use anyway. Thanks Richard G. Roberto [EMAIL PROTECTED] 011-81-3-3437-7967 - Tokyo, Japan -- *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> "Pete" == Pete Templin <[EMAIL PROTECTED]> writes: Pete> Keep in mind that we are all getting a generally fantastic Pete> product for the best price anyone could ask for. Hear, hear. Pete> Dselect might lead you Pete> astray. But accept what the Debian project has given each Pete> of us, and send a few thanks to each and every person who Pete> has contributed their own time to simplify your life, to Pete> make it possible for you to experience UNIX with a minimum Pete> of effort on a variety of hardware. The project leader has Pete> managed to get a few emails onto the list while cleaning out Pete> from a devastating flood. That's what I call dedication. Hear, hear. Pete> How about we all take a step or two back and peek at what is Pete> in front of us? There's a lot there. It may not be the Pete> best it can be yet, but it's quite fine in its current form Hear, hear. -- Nathan L. Cutler Linux Enthusiast http://www.cise.ufl.edu/~nlc -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
>So, in hindsight, it was necessary to get my hands dirty, and see how >bad upgrading, and maintenance could be before I found Debian. I agree. I started off much the same way (only I started with SunOS, found how yucky upgrading was, found slackware nicer and then found debian a few months ago, we are still in the process of swapping over all of our servers to debian). My point however is that it would be nice if beginners could "get their hands dirty" *with* debian. It shouldn't be to hard to make a simple front end for dpkg (or a simplified dselect) which the beginner *could* use. >Now really, how much can a complete novice really do with a new Linux >machine. It takes an investment of time, energy, and interest to >learn even the simplest of tasks, but once you know them ;-) Agreed. I've been a sysadmin for 3 years now. It takes a lot of time to get your head around UN*X, especially if you came from a Windows/Mac background and don't have much/any programming experience. The fact that it takes effort is no reason to make it harder. In my mind debian has two things going for it. First, and the reason I changed, is that it makes maintaining multiple systems (new versions, bug fixes etc) *much* easier; second that it provides a good starting point for learning *without* needing to know how to compile programs from scratch. >I think we can all agree that a complete beginner is going to have >trouble installing any form of Linux/BSD/and yeah maybe even Win95 >if they don't do a little >research first. When I started I had no idea what a MTA is much less >which one I'd like to use. ;-) but gawd to have such a choice ;-) Exactly. Lets make it as easy as possible for them to get something they can use working (which it nearly is already) rather then say that since it's going to be hard there's no point trying to make it easy. >I think it is more important to help complete novices learn a little >about what is possible with their new O/S and let them investigate >what _they_ want to. Yeah it may take some time to get a fully >functional system, but that is how everyone else here did it, right? I think the fact that Debian is free is a non-issue. It has nothing to do with the problem. Helping them learn is important, and educating them on what the choices mean is important. But a very good tool to help that education would be a working linux system! >Agreed, but I really think that Linux isn't your Moms operating >system, and hope it never really is. I don't think it has much to offer the average mom and pop, *but* if they want to use it more power to them. Lets help them. >I'm not picking on you Adam, I just don't understand the barrage of >attacks on dselect, when this novice, really finds it a joy compared >to the alternative. I know, everyone just wants it to be the best it >can be, buts lets face it, dselect accomplishes a huge amount of work, in >a short time with a huge number of options, and only pukes when it is >sick. Couldn't ask any more, considering what we paid for it anyway ;-) I'm not picking on dselect, it's the best tool that I've ever used to maintain any UN*X system. I am commenting on ways to make *starting* with Debian easier. One stubling block for new users is dselect. It is not very intuitive and takes a while to get your head around. >Thanks to the Maintainer, and kudos. Agreed :) Adam. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Those are words well spoken... > > On Tue, 7 Jan 1997, Martin Konold wrote: > > > Yes, a very good point. I am offering a host for a mailing list. > > We should first figure out how it should work and implement it > > afterwards. There is definetelly a need for a improved dselect. > > > > Actually why is the maintainer so silent? > > Perhaps you would be silent if discussions about your package were turning > into some semi-serious bash N trash sessions. I'd like to offer my two > cents about Debian and dselect: > > Most of us are brand new to Linux or are advancing up the UNIX ladder when > we install Debian on a machine. Personal computers offer an ability to > experiment that the departmental or enterprise server won't give us. With > that experimentation comes a few oopses and a few lessons learned. With a > true multitasking, multiuser system comes certain hurdles about the boot > process and services (daemons). > > Keep in mind that we are all getting a generally fantastic product for the > best price anyone could ask for. I've never been involved in the > development of any of the DEC boxes which handle our campus net services, > but I believe the standard sequence goes like this: > > get and compile gcc with the cc that came with the machine. > get and compile emacs with gcc. > get and compile tcsh, now that you can edit Makefiles with emacs. > get and compile perl, now that you've got a shell you're familiar with. > get and compile sendmail, so email can actually flow. > > Heaven forbid one of us gets a compilation error, and wait until it's time > to build inn! > > Take your time with Linux. I openly admit that I had overly high > expectations the day my first Pentium arrived. Now that I've finally > acquired my second Pentium > (http://www.bucknell.edu/~templin/pages/computer if you're curious), I let > one run Linux 24/7, and try new packages on the other. Mistakes will > happen. Dselect might lead you astray. But accept what the Debian > project has given each of us, and send a few thanks to each and every > person who has contributed their own time to simplify your life, to make > it possible for you to experience UNIX with a minimum of effort on a > variety of hardware. The project leader has managed to get a few emails > onto the list while cleaning out from a devastating flood. That's what I > call dedication. > > How about we all take a step or two back and peek at what is in front of > us? There's a lot there. It may not be the best it can be yet, but it's > quite fine in its current form, and a menu-driven is certainly a step up > from the command-line origins of UNIX. > > That said, who is willing to coordinate efforts toward gathering > suggestions for dselect, and what is the next step that we need to take? > I also have a machine which I am willing to offer up towards mailing > lists, disk space, web pages, or whatever. Let me know how I might help. > > > --Pete > ___ > Peter J. Templin, Jr. Client Services Analyst > Computer & Communication Services tel: (717) 524-1590 > Bucknell University [EMAIL PROTECTED] > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] > -- Ørn Einar Hansen [EMAIL PROTECTED] [EMAIL PROTECTED] fax; +46 035 217194 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Hello I think the ide of a simpel istall-tool as a compliment to dselect wery-much-as-it-is is a god ide. Making dselect more a mangement tool then an install tool. Dselect is a good managment tool, but less god first install tool for inexperient users. Most of the problems that comes with dselect comes of less sucessfull atempt to be a install tool for a novice. One is the way dselect treats recomend dependece. The intension, as I understand it, is to give more guidance to novice users. To some extent it do help keeping systems sane, but ther MUST (IMHO) still be a way to tell dselect to treat recomends like it treats sugests. A comand line toggel wold do. Also a experient user gain allot from using dselect, so ponting att dpkg as an alternativ is not the answer her. This leaves us with to questions o How to inprove dselect further as an mantain-tool. I find most of the previus posters 'smal' sugestions, like inproved searches, less noice, logging e t c being god and construktive ones. o How a simpel install-tool may look. To open a third question, when debian is first run dselect starts automagicaly, then disapers from the startup equaly automagicaly. IMHO it is better to start some 'debian install/maintain menu' from root bashrc (or what ewer). dselect, the new install tool, the basic docs, posably some of the tools from the install disks (module config, kebordsettup, systemname setupp etc) and a shell is nice fings for that menu. That menu shuld not disaper automagicaly! Anny user not noving how to remove it will not want to remowe it! It's great for a novice to have all the basic stuff handy in place. This new esy-install-tool and smal fixes to dselect will fast make debian better an more atractiv without loosing anny old featurs. In the long run i think dselect should work aganst some library that works both from a terminal and from X and svgalib e t c with the same aplication source. Big changes (if neded) can wait untill this rewrite. I am working on one, but the documentation is poor and even worse (for most of You) only in Swedish. In short, it's intended to be som kind of 'Meta library' or wraparound not implementing much self if its alredy availbly. But giving one programming-interface to allot of userinterface. Also making it 'esy' to add new user interface. Anyway, it not in a usefull state yet. If annyone is intrested, mail me and I mail back when i have some desent documentation on my Webpage. At that time, any help will be welcome! Pleace dont expect rapid reply, I do not have all the time i want :( Sorry for my poor english /Lars -- / / _/_ _/_ Lars Hallberg IT-konsult Micro++ /\_/\ / / www.micropp.se/lahwww.micropp.se / Micro++OOP C++ WWW-Design Utbildning LINUX FreeWare -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> I think that this is a great idea. One of the things that keeps Slackware > alive is that fact that it is *so* easy to install (even if it is buggy and > a nightmare to maintain). My background is this: Had my computer for a year. Never heard of Linux until Apr'96. Started with a CD that had Slack, and RedHat on it. Used slack until sometime in Sept or Oct.'96, then went to Debian. (Found Red hat too confusing to install at first) So, in hindsight, it was necessary to get my hands dirty, and see how bad upgrading, and maintenance could be before I found Debian. I really did think that buying a CD was the best choice until about a month ago, when I started living off the unstable tree. I just point dselect at the ftp site ~once a week, and I am a happy camper. To me the tools contained within any Unix system are almost bound with functionality to the Internet, and with bug fixes, security fixes, ect. the only way to keep up is via Internet, and dselect does this very well. Now really, how much can a complete novice really do with a new Linux machine. It takes an investment of time, energy, and interest to learn even the simplest of tasks, but once you know them ;-) > > If there were a way to install debian, easily, so that the beginner could > do it then it would be really nice. Just group packages into basic groups > and make the dependacy selections for them. If they need something else to > run the package they need then just install it for them and don't bother > telling them. I think we can all agree that a complete beginner is going to have trouble installing any form of Linux/BSD/and yeah maybe even Win95 if they don't do a little research first. When I started I had no idea what a MTA is much less which one I'd like to use. ;-) but gawd to have such a choice ;-) I think it is more important to help complete novices learn a little about what is possible with their new O/S and let them investigate what _they_ want to. Yeah it may take some time to get a fully functional system, but that is how everyone else here did it, right? Do we need to remind people that even though they bought their CD, the software on it is free, an impressive array of tools at your disposal I'd say. As M$uck what they'd charge for such a package. > > I think the most important thing that that they can get it up and running > with as few headaches and confusing messages as possible. Agreed, but I really think that Linux isn't your Moms operating system, and hope it never really is. > > Once the system is installed then they can go on to dselect (or dpkg) to > fine tune which packages they want, *after* they have it working. > > Adam. > > I'm not picking on you Adam, I just don't understand the barrage of attacks on dselect, when this novice, really finds it a joy compared to the alternative. I know, everyone just wants it to be the best it can be, buts lets face it, dselect accomplishes a huge amount of work, in a short time with a huge number of options, and only pukes when it is sick. Couldn't ask any more, considering what we paid for it anyway ;-) Thanks to the Maintainer, and kudos. To the other newbies out there, this mailing list somehow ends up archived as a newsgroup. I've found lots of help by searching problems at http://www.dejanews.com/ Rich M [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Ian Jackson is listed as the maintainer of the dpkg package which contains dselect. I just sent him a short note letting him know that there is a group of users who wish to help improve dselect, and asking for his guidance. If he is very busy, he may prefer not to be a member of the dselect project mailing list, but instead keep in contact with a single representative of the group. I noticed from the Debian web page that he tops the list of maintainers with 141 outstanding bugs. I am certain that this is due to his central role in the project and not due to any lack of effort. Last year I read one of the mailing lists which he quite was active on, and for several months I thought that he was the Ian in Debian. I still consider him "the other Ian in Debian." It looks to me like he could use some help. I suggest that we await his response and guidance. While checking out the Debian web page, I notice that there is a debian-dpkg mailing list mentioned, but no archived messages are available for it. Does anyone know the story behind that. Kirk Hilliard -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Good idea! On Tue, 7 Jan 1997 [EMAIL PROTECTED] wrote: > > I agree that dselect has some problems for users who are new to it. I > too have seen people who where experienced with unix and who were > mystified by dselect at first. I suppose that means that there is > room for improvement, even if I personally don't find much wrong with > dselect the way it is. Just don't make me use a mouse ;^) > > Whatever the user interface -- I wonder if many of the problems new > users have with dselect couldn't be taken care of with a menu of > canned installations, "typical user", "web developer", "graphics > guru", "everything including the kitchen sink", etc. > > > > > > > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] > > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Wed, 08 Jan 1997 15:42:27 +0100 Gertjan Klein ([EMAIL PROTECTED]) wrote: > One of my most serious criticisms is the fact that in spite of the > dependencies being known, packages aren't installed in the right order. > If package 1 depends on package 2, then package 2 *must* be installed > *first*. This isn't done; I consider this a bug, that should be > reported. Not a bug. What you describe is pre-dependencies. It's a bit too long to explain here, but you can find all the details in the Debian policy manual. Dpkg does the work right... so far. Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
In article <[EMAIL PROTECTED]> you write: >Actually why is the maintainer so silent? > >Is dselect still maintained? AFAIK Ian is currently busy finishing his PhD thesis, but has promised he'll do some work on dselect soon. -- Steve McIntyre, CURS Secretary, Cambridge, UK. [EMAIL PROTECTED] Also available from [EMAIL PROTECTED] "Can't keep my eyes from the circling sky, +-- "Tongue-tied & twisted, Just an earth-bound misfit, I..." |Finger for PGP key -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
This is getting a little bit off topic, but is there a working group for making Debian easier to install? Not just dselect, but the documentation, the layout and organization of www.debian.org, the whole works? If there is, I want to get involved with it because I am starting a project now that I've been thinking about for some time: making a custom Debian "distribution" geared toward writers, artists and other creative types who don't have much knowledge of Linux to start with. I think we're reaching the time where such a thing is possible, what with the quality and scope of the software that's out there. What has to be done now is ease of installation and the whole package maintenance thing, more tutorials (both paper and digital, including interactive, like a "training shell" perhaps). I know this is a large undertaking -- in the extreme sense, where a Linux/UNIX total beginner buys one of these machines with Linux installed, they're going to need help with administration. Actually, they're going to need someone _else_ to administer it. So I wonder about the feasability of some "volunteer Linux administration network," where the end-user has their machine connected to the net via a dialup line and this volunteer network has an admin account on the machine where they can go in and perform routine tasks that need to get done. Or volunteer members get "sponsor" users who are geographically near them, and only that volunteer has admin access to the machine. Maybe this could be tied in with all the Linux user groups that are sprouting up everwhere, I don't know -- just some open thoughts for debate. m Michael Stutz | DESIGN SCIENCE LABS http://dsl.org/m | Hypermedia, Internet, Linux/GNU bumper stickers,indie rock,rants | Linux: http://dsl.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Pete Templin <[EMAIL PROTECTED]> wrote: > On Tue, 7 Jan 1997, Martin Konold wrote: >> Actually why is the maintainer so silent? > Perhaps you would be silent if discussions about your package were turning > into some semi-serious bash N trash sessions. If s/he (or you) interprets at least _my_ remarks as "bash N trash sessions", we've misunderstood each other. I have no desire to put down dselect and friends; I think the Debian package management is wonderful, especially the dependency checking. I do, however, have seconded some remarks (and made some myself) about serious problems with the current user interface and functionality. As far as I'm concerned, these remarks are intended in a positive way, i.e. to let the maintainer know what problems were found, and to suggest improvements. One of my most serious criticisms is the fact that in spite of the dependencies being known, packages aren't installed in the right order. If package 1 depends on package 2, then package 2 *must* be installed *first*. This isn't done; I consider this a bug, that should be reported. Perhaps it is important to recognize that different viewpoints lead to different evaluations. I'm sure dselect does everything the maintainer feels it should do, and in the right way - and from his/her viewpoint s/he is probably right. My viewpoint is one of a *nix newbie, used to DOS (is may not be much of an OS, but lots of *nix programs can learn a lot about user-friendliness from DOS programs). It is important for me to have an errorfree, even warning-free install - because I don't know what to do with all these warnings. And I'm a commandline person - imagine what it's like for someone used to W95? > Keep in mind that we are all getting a generally fantastic product for the > best price anyone could ask for. Please don't bring in that "but it's free" stuff. I have great respect for the fact that Debian is developed entirely by volunteers (in fact, it being non-commercial is one of the reasons I chose this distribution even though it would have cost me the same to get e.g. redhat). Nevertheless, a lot of people depend on it now, and may expect the maintainers to strive for improvement. (I second the "generally fantastic" bit, BTW). > That said, who is willing to coordinate efforts toward gathering > suggestions for dselect, and what is the next step that we need to take? There - this is what we were talking about! Not bashing, but gathering suggestions for dselect! In my opinion, though, the next step is for the maintainer of dselect to come out of hiding ;-) and tell us what s/he thinks about the suggestions and problem reports so far. Gertjan. [PS - please don't Cc me in your messages directly - I'll get it via the mailing list, thank you] --- -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> "Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:
Hamish> Pressing / and entering the same search just takes you
Hamish> back to the first result again. This is counter-intuitive
Hamish> for users of vi, less etc. Lynx uses "n" to repeat a
Hamish> search but dselect doesn't use that either.
I thought the same thing. It should work like 'less' does. And have
{C-s} and {C-M-s} incremental searching like Emacsen do as well,
perhaps.
Hamish> We should certainly not force a particular editor down
Hamish> anyone's throat, especially emacs :-)
Maybe 'dselect' could have a 'viper' (vi emulator) built into it
too... Or, more realisticly, dual bindings/modes like BASH and other
'libreadline.so' programs have... Set an environment variable?
Hamish> hamish (vi fan)
-- Yet another Emacs fanatic. (go supercite! yeah.)
__ _Karl M. Hegbloom <[EMAIL PROTECTED]>
/ /(_)_ __ _ ___ __ http://www.inetarena.com/~karlheg
/ / | | '_ \| | | \ \/ / Portland, OR, USA
/ /__| | | | | |_| |> < Proudly running Linux 2.0.27 transname
\/_|_| |_|\__,_/_/\_\ and Debian GNU public software!
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Pete Templin wrote: > > On Tue, 7 Jan 1997, Martin Konold wrote: > > > Actually why is the maintainer so silent? > > Perhaps you would be silent if discussions about your package were turning > into some semi-serious bash N trash sessions. I'd like to offer my two > cents about Debian and dselect: [Big snip] > How about we all take a step or two back and peek at what is in front of > us? There's a lot there. It may not be the best it can be yet, but it's > quite fine in its current form, and a menu-driven is certainly a step up > from the command-line origins of UNIX. There's no question about that. I completely agree with you on this point, as i agree on the snipped part. Simply, new users are always frightened by dselect. Personally i begin to apreciate it. Six month ago i switched to debian from an old hand maintained slackware 3.0, i was lost in the hierarchical-but-fully-diplayed dselect menu. I spent 45 minutes fine tuning my selection. Big mistake. dpkg got screwed by something that i don't remember (was debian 1.1.0), I had to reinstall everything. Now i always tell to people switching to debian to accept the defaults, only modifying the X server config, and the run dselect by adding little by little. That's the whole strength of debian. But brend new users don't even knows what emacs or gcc or whatever is. We need, rather than bash N trashing dselect, a simple first screen with some installation template. One for new users, one for coarse customization (as someone told about BSDI), one for fine tuning, giving acces to the actual dselect. Things like Tk based config can wait, but this "joe user template" should be added ASAP, So i will stop recommending Redhat to peoples having zero knoeledge of linux but wanting to try it. Anyway, your work on dselect is IMHO great, at least for users acquainted with this tool. > That said, who is willing to coordinate efforts toward gathering > suggestions for dselect, and what is the next step that we need to take? > I also have a machine which I am willing to offer up towards mailing > lists, disk space, web pages, or whatever. Let me know how I might help. > > > --Pete > ___ > Peter J. Templin, Jr. Client Services Analyst > Computer & Communication Services tel: (717) 524-1590 > Bucknell University [EMAIL PROTECTED] > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] > -- Philippe Strauss, CH-1092 Belmont Email: <[EMAIL PROTECTED]> Homepage: http://sicel-home-1-4.urbanet.ch -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Problems I have seen with dselect: causes serial port overruns, don't know if dpkg does too. any options from the main menu that causes the cdrom to be read must be selected twice in order for it to work. it scans each possible package and determines its state when installing new packages, resulting in a big waste of time when you just want to install one package. In my opinion, dselect is a fairly user friendly environment that beats the heck out of dpkg, except for those three problems that I have iterated above. Hope this helps someone with dselect. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Tue, 7 Jan 1997, George Bonser wrote: > > In my opinion, dselect is the single biggest stumbling block standing in the > way of greater acceptance of Debian linux. > > I have seen new users become so frustrated with it that they have thrown the > CD against a wall. That doesn't mean anything. I throw CDs against the wall all the time for no reason at all. Are you sure they were frustrated? Maybe they're just as fascinated as I with winging 'em across the room! ;-) Richard G. Roberto [EMAIL PROTECTED] 011-81-3-3437-7967 - Tokyo, Japan -- *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
In my opinion, dselect is the single biggest stumbling block standing in the way of greater acceptance of Debian linux. I have seen new users become so frustrated with it that they have thrown the CD against a wall. -- George Bonser [EMAIL PROTECTED], [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Wed, 8 Jan 1997, Hamish Moffatt wrote: > I don't use emacs, but to me dselect seems to be already too > emacs-oriented. For example, searching for a package is done with /, > but how do you repeat the search? I haven't studied the help > in much detail, but for me the answer is "I don't know" presently. It's "\". "/" isn't a special key in emacs. Lotus 1-2-3 maybe. > (vi fan) Oh, well. In that case, click here: o ;-) ...RickM... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Tue, 7 Jan 1997 [EMAIL PROTECTED] wrote: > Over the last year, I've done many installations and upgrades of > debian using dselect. During that time, I've learned how to use it -- > and I find it quite comfortable use. What you are used to is easy, I > guess. Since we seem to be picking on dselect's user interface again, > I wish it had more "emacs-like" key bindings, but it's a marvelous > tool as it is, IMHO. > The same here as i have to admit. I installed Debian the first time half a year ago and *hated* dselect. I remember that a complaint of mine to the list about it's awkwardness and counter intuitive interface started one of these regularilyy reappearing discussions about dselect. In the meantime i have become used to it and feel almost comfortable with it although i still consider it to be awkward and counter intuitive. You still do have to read it's documentation because almost everything of the keybindings seems to be non standard. I too wished it had at least emacs or vi key bindings for a start. > Whatever happens to dselect, I would hate to have it move to X, which > is not the first thing I want to figure out with a new machine, or to > any interface that _makes_ me take my hands off the keyboard. Just > another data point. > I don't care for any X version although it could probably enhance the program somehow like the xconfig thing from the kernel has proven as well. In an xterm you can always fire up any console program but the reverse is probably not exactly true, isn't it? Regards, P. *8^) -- Paul Seelig [EMAIL PROTECTED] African Music Archive - Institute for Ethnology and Africa Studies Johannes Gutenberg-University - Forum 6 - 55099 Mainz/Germany Our AMA Homepage in the WWW at http://www.uni-mainz.de/~bender/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Tue, 7 Jan 1997, Martin Konold wrote: > Yes, a very good point. I am offering a host for a mailing list. > We should first figure out how it should work and implement it > afterwards. There is definetelly a need for a improved dselect. > > Actually why is the maintainer so silent? Perhaps you would be silent if discussions about your package were turning into some semi-serious bash N trash sessions. I'd like to offer my two cents about Debian and dselect: Most of us are brand new to Linux or are advancing up the UNIX ladder when we install Debian on a machine. Personal computers offer an ability to experiment that the departmental or enterprise server won't give us. With that experimentation comes a few oopses and a few lessons learned. With a true multitasking, multiuser system comes certain hurdles about the boot process and services (daemons). Keep in mind that we are all getting a generally fantastic product for the best price anyone could ask for. I've never been involved in the development of any of the DEC boxes which handle our campus net services, but I believe the standard sequence goes like this: get and compile gcc with the cc that came with the machine. get and compile emacs with gcc. get and compile tcsh, now that you can edit Makefiles with emacs. get and compile perl, now that you've got a shell you're familiar with. get and compile sendmail, so email can actually flow. Heaven forbid one of us gets a compilation error, and wait until it's time to build inn! Take your time with Linux. I openly admit that I had overly high expectations the day my first Pentium arrived. Now that I've finally acquired my second Pentium (http://www.bucknell.edu/~templin/pages/computer if you're curious), I let one run Linux 24/7, and try new packages on the other. Mistakes will happen. Dselect might lead you astray. But accept what the Debian project has given each of us, and send a few thanks to each and every person who has contributed their own time to simplify your life, to make it possible for you to experience UNIX with a minimum of effort on a variety of hardware. The project leader has managed to get a few emails onto the list while cleaning out from a devastating flood. That's what I call dedication. How about we all take a step or two back and peek at what is in front of us? There's a lot there. It may not be the best it can be yet, but it's quite fine in its current form, and a menu-driven is certainly a step up from the command-line origins of UNIX. That said, who is willing to coordinate efforts toward gathering suggestions for dselect, and what is the next step that we need to take? I also have a machine which I am willing to offer up towards mailing lists, disk space, web pages, or whatever. Let me know how I might help. --Pete ___ Peter J. Templin, Jr. Client Services Analyst Computer & Communication Services tel: (717) 524-1590 Bucknell University [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> On Tue, 7 Jan 1997 [EMAIL PROTECTED] wrote: > Dear Developers, > > guess. Since we seem to be picking on dselect's user interface again, > > I wish it had more "emacs-like" key bindings, but it's a marvelous > > tool as it is, IMHO. > > PLEASE, please, please do not confront people with 'emacs-like' > keybindings. This would scare away newbies without impressing > experienced people too much. The more experienced people > quite often use plain dpkg and are happy with these cli-tools. I don't use emacs, but to me dselect seems to be already too emacs-oriented. For example, searching for a package is done with /, but how do you repeat the search? I haven't studied the help in much detail, but for me the answer is "I don't know" presently. Pressing / and entering the same search just takes you back to the first result again. This is counter-intuitive for users of vi, less etc. Lynx uses "n" to repeat a search but dselect doesn't use that either. We should certainly not force a particular editor down anyone's throat, especially emacs :-) hamish (vi fan) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
>I have a really radical suggestion, and that is to split off the >installation process from dselect. Have a dinstall and rename dselect to >dmanager or something. Then make dinstall a much simpler, less >featureful tool, that offers to install groups of packages to fit >various usages. One of my favorite installation tools is the simple one I think that this is a great idea. One of the things that keeps Slackware alive is that fact that it is *so* easy to install (even if it is buggy and a nightmare to maintain). If there were a way to install debian, easily, so that the beginner could do it then it would be really nice. Just group packages into basic groups and make the dependacy selections for them. If they need something else to run the package they need then just install it for them and don't bother telling them. I think the most important thing that that they can get it up and running with as few headaches and confusing messages as possible. Once the system is installed then they can go on to dselect (or dpkg) to fine tune which packages they want, *after* they have it working. Adam. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Tue, 7 Jan 1997, Michael Stutz wrote: > In concept, dselect is great. It's an attempt to create a user interface > that's not based on the window/pulldown menu interface that (I believe) is I totally agree with you. What often confuses me about dselect is that it sometimes when running into dependency conflicts changes my tagging (which packages to install). This takes control from the user, which should be avoided. About what could be made easier in Debian: I gave Debian 1.2 to two people who has little or no experience with Linux. They both made the same mistake, not installing the 16 color X server. This should be clarified, that you will need it because it provides things essential to configuring X. // Jonas <[EMAIL PROTECTED]> [2:201/262.37] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On 7 Jan 1997, John Henders wrote: > In <[EMAIL PROTECTED]> Gertjan Klein <[EMAIL PROTECTED]> writes: > I have a really radical suggestion, and that is to split off the > installation process from dselect. I agree.. However, how about automatically installing the first round of "stuff" without a full dselect. I've run into dependency problems if I select a lot of stuff that first time dselect automagically appears. (I don't if I only install the preselected things.) Those that don't want an automatically installed package can always uninstall it later. |This is OFFICIAL WRITTEN notification that I want to be REMOVED| |from ALL commercial mailing lists. EVERY message sent from this | | account has had this request posted. ALL UNSOLICITED ADVERTISEMENTS | | SENT TO THIS ACCOUNT ARE IN VIOLATION OF FEDERAL (U.S.) LAW. | | Opinions expressed are not necessarily those of Cyclades Corporation. | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Tue, 7 Jan 1997 [EMAIL PROTECTED] wrote: > I agree that dselect has some problems for users who are new to it. I > too have seen people who where experienced with unix and who were > mystified by dselect at first. In concept, dselect is great. It's an attempt to create a user interface that's not based on the window/pulldown menu interface that (I believe) is highly overrated. It's nice because for whatever use a window system has, it's not the only way to do things. I do not believe that it is "gui (windows) vs. command line." Those are only two ways. dselect is different and I like that. The problem with dselect, I think, is that the user quickly gets lost in the context. Think of using a computer program as watching a movie: there's a certain sequence to it and it will make sense. It's like dselect skips a sequence somewhere, gets too much into its own terminology too quickly, and the user's lost. Bottom line is I think dselect's a good thing but something has to be changed. Maybe dselect doesn't go far _enough_ in it's direction, I don't know. But Debian can be difficult to install and to do package maintenance, and that has to change. Michael Stutz | DESIGN SCIENCE LABS http://dsl.org/m | Hypermedia, Internet, Linux/GNU bumper stickers,indie rock,rants | Linux: http://dsl.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
In <[EMAIL PROTECTED]> Gertjan Klein <[EMAIL PROTECTED]> writes: >Kirk Hilliard wrote: >[A nice list of suggested dselect improvements, which I mostly agree >with] >In addition, I think the following improvements are important: > - Create a log file containing *everything* that is output to the >screen (stdout and stderr). I noticed more than one package complaining >it couldn't fully configure itself for one reason or other, and telling >me I could redo the configuration manually by running "xxx". It is not >nice to have to write this down. If people are concerned about disk >space, a menu choice could be to clear the log file. > - Whenever a package returns an error when installing, present the >user with the option to stop installation entirely (so the problem can >be delt with), or continue with the next package. I have a really radical suggestion, and that is to split off the installation process from dselect. Have a dinstall and rename dselect to dmanager or something. Then make dinstall a much simpler, less featureful tool, that offers to install groups of packages to fit various usages. One of my favorite installation tools is the simple one that comes with BSDI, which basically has about 30 selections that you can select to install, with X, development, X development, and other relatively natural broad categories of installation packages. This allows a very fast simple method to get a system up that is roughly what you want. Then, after these base and extrapackages are installed and configured, you would use dmanage(formerly dselect) to tune the existing instal, add all the custom optional packages you want, and finally to help you upgrade all your installed packages as you need. -- John Henders - System Administrator - Mindlink!/Wimsey -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
I agree that dselect has some problems for users who are new to it. I too have seen people who where experienced with unix and who were mystified by dselect at first. I suppose that means that there is room for improvement, even if I personally don't find much wrong with dselect the way it is. Just don't make me use a mouse ;^) Whatever the user interface -- I wonder if many of the problems new users have with dselect couldn't be taken care of with a menu of canned installations, "typical user", "web developer", "graphics guru", "everything including the kitchen sink", etc. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Tue, 7 Jan 1997, Gertjan Klein wrote: Thanks for your nice proposal. I like it very much. > The kernel 'make menuconfig' is a nice example. This is IMHO an excellent example how it could be done. In the kernel hierachy you might enter: 'make config' 'make menuconfig' 'make xconfig' Every time you get a folding editor like choice. You might use plain tty, ncurses or even tcl/tk. All these mathods are based on the same data, so that driver developers may provide a single file with the help info etc. I do think you know how it is working... > > Unless a group like this is already in place, I propose that we form a > > working group to initially hash out how dselect should be improved, > > and then to actually implement those improvements. Yes, a very good point. I am offering a host for a mailing list. We should first figure out how it should work and implement it afterwards. There is definetelly a need for a improved dselect. Actually why is the maintainer so silent? Is dselect still maintained? Yours, -- martin // Martin Konold, Muenzgasse 7, 72070 Tuebingen, Germany // // Email: [EMAIL PROTECTED] // Linux - because reboots are for hardware upgrades -- Edwin Huffstutler <[EMAIL PROTECTED]> -- Just go ahead and write your own multitasking multiuser os ! Worked for me all the times. -- Linus Torvalds -- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
On Tue, 7 Jan 1997 [EMAIL PROTECTED] wrote: Dear Developers, > Over the last year, I've done many installations and upgrades of > debian using dselect. During that time, I've learned how to use it -- > and I find it quite comfortable use. What you are used to is easy, I > guess. Since we seem to be picking on dselect's user interface again, > I wish it had more "emacs-like" key bindings, but it's a marvelous > tool as it is, IMHO. PLEASE, please, please do not confront people with 'emacs-like' keybindings. This would scare away newbies without impressing experienced people too much. The more experienced people quite often use plain dpkg and are happy with these cli-tools. IMHO thee should be an easy accessible online help for dselect which explains the accellerator keys and the concept in short. How about a ncurses approach? Folding editopr like? nc like?... Please make dselect user friendly and easy to understand. It is the front door of Debian to first time users. ALL users to whom I recommended Debian (even the experienced) users complained so far about dselect as beeing hard to use. These people mostly complained about the keybindings and endless depenency problems. They sometimes seems to be caught by help screens of which they do not know how to get rid of them... A lot of these problems have already been addressed in this list. Yours, -- martin // Martin Konold, Muenzgasse 7, 72070 Tuebingen, Germany // // Email: [EMAIL PROTECTED] // Linux - because reboots are for hardware upgrades -- Edwin Huffstutler <[EMAIL PROTECTED]> -- Just go ahead and write your own multitasking multiuser os ! Worked for me all the times. -- Linus Torvalds -- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Kirk Hilliard wrote: [A nice list of suggested dselect improvements, which I mostly agree with] In addition, I think the following improvements are important: - Create a log file containing *everything* that is output to the screen (stdout and stderr). I noticed more than one package complaining it couldn't fully configure itself for one reason or other, and telling me I could redo the configuration manually by running "xxx". It is not nice to have to write this down. If people are concerned about disk space, a menu choice could be to clear the log file. - Whenever a package returns an error when installing, present the user with the option to stop installation entirely (so the problem can be delt with), or continue with the next package. - Most important of all, build a dependancy list for the selected package, and start installing at the low end (the packages not depending on anything else). I did a fresh install and ran into tons of error messages about dependancies not being fulfilled. Rerunning dselect a few times solved (most of) these problems, as the stuff the problematic package depended on was installed by then, but this is _ugly_. I made a concious choise for Debian, having heard lots of nice things about the package management and ease of installation. I'm still happy with my choise, but even Debian has a long way to go before it will convince the average W95 user that Linux is usable for non-wizards. > I. Less clutter > A. Present packages like a folding editor, so the initial > presentation is quite compact. The kernel 'make menuconfig' is a nice example. > Unless a group like this is already in place, I propose that we form a > working group to initially hash out how dselect should be improved, > and then to actually implement those improvements. With the disclaimer that I'm not exactly a *nix guru, I'd like to contribute to such a group. Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> The Boot Control home page: http://www.xs4all.nl/~gklein/bcpage.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Over the last year, I've done many installations and upgrades of debian using dselect. During that time, I've learned how to use it -- and I find it quite comfortable use. What you are used to is easy, I guess. Since we seem to be picking on dselect's user interface again, I wish it had more "emacs-like" key bindings, but it's a marvelous tool as it is, IMHO. Whatever happens to dselect, I would hate to have it move to X, which is not the first thing I want to figure out with a new machine, or to any interface that _makes_ me take my hands off the keyboard. Just another data point. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
> David Gaudine wrote: > > ... maybe this has warped my attitude. But personally, I don't want > > to even *think* about installing X on a system until I've already > > installed everything else. > > Dselect is not only Debian's face to the world, it is also an > administrative tool which should be quick, powerful, and convenient > for even experienced administrators to use. Sounds terrific. On a related note, aside from your (very correct, imho) list of dselect problems, it seems to do some very stupid things sometimes. I keep a directory /usr/local/deb full of packages I've downloaded (since I don't use dpkg-ftp due to slow PPP link, and don't have a 1.2 CD yet). I keep a directory structure there similar but not identical to the proper site. I have dselect scan these packages when I pick Update, which it does ok. However when I pick install, if I have two versions of a package in my directory, dselect will often install the newer then later replace it with the older! Especially if the older is in a later directory. I'm not sure if it occurs if they're in the same directory. I prefer dpkg by hand. When I'm searching for a package, I download Packages.gz and use less; even dselect's search is very cumbersome. Adding additional packages during the installation other than the recommended set seems to be a recipe for disaster too. hamish -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: A proposal to improve dselect
Kirk Hilliard wrote: > I absolutely agree. While an X based version of dselect might be > nice, what with the added utility of a mouse, scroll bars, and > possible multiple windows, the text based dselect must have the same > functionality and almost nearly the same ease of use. That's what I was thinking about...of course there should be a text based version too, for all the people who do not want or do not need X. Maybe it would be better to have only ONE installer instead of dselect and dpkg. Because I'm a newbie I'd personally love an EASY installation using X (of course with a X version supporting my hardware). E.g. I loved to compile the kernel using make xconfig. All was easy to survay, of course the help provided for some options could be better. The help given by dselect does not give to me (a newbie) sufficient information (about some packages) whether I need a package or not and what the packege is supposed to do. > 2. Alternatively, let the non-error status messages overwrite > each other. > 3. Alternatively, show the non-error status messages in a > separate window. What U think about dselect showing a summary of the messages at the end of the installation which U could scroll or something. Why dselect has to produce error messages at all?? It should prevent errors in a way. Dselect has to become more intelligent and user friendly and allow an easy installation for a newbie too. > C. Mouse option (and even X) > 1. Let it optionally run as a gpm client. The mouse could be > used to scroll (would scroll bars be appropriate even > without the mouse?), expand headings (as with the folding > editor), and toggle package markings. > 2. Port it to X, with the same functionality as the souped up > text based version, but prettier (in some people's eyes). Yes in my eyes it IS much prettier and will be hopefully EASY to use:-))) > Unix *is* user friendly -- it's just picky about who it makes friends > with. Let's make dselect more sociable. It was very picky about me:-))) Greetings Jacek
A proposal to improve dselect
David Gaudine wrote: > ... maybe this has warped my attitude. But personally, I don't want > to even *think* about installing X on a system until I've already > installed everything else. I absolutely agree. While an X based version of dselect might be nice, what with the added utility of a mouse, scroll bars, and possible multiple windows, the text based dselect must have the same functionality and almost nearly the same ease of use. John Henders just posted a very honest review of Debian 1.2 as distributed on the Infomagic CD set. I think that some of the problems he mentioned are specific to the Infomagic CD, and hopefully the rest are being identified and will be cleaned up soon. (Should Debian 1.2 have been called 1.2 beta?) More to the point, he suggested several dselect improvements. Borrowing from his message and from several others, here is a short list I. Less clutter A. Present packages like a folding editor, so the initial presentation is quite compact. B. Avoid showing the help screen every time the mode changes. C. Distinguish between over abundant status messages, trivial warnings, and serious errors. 1. Suppress all non-error status messages shown during "Install" mode, optionally writing them to a file. (Not only is it annoying to see the repeated messages, but when I do get an error it scrolls off the screen and out of the scroll back buffer before I can read it.) 2. Alternatively, let the non-error status messages overwrite each other. 3. Alternatively, show the non-error status messages in a separate window. II. Friendlier, more intuitive interface A. Exiting "Select" mode 1. The key should not Confirm and quit. (I find this very counter intuitive.) 2. When you select exit/quit you should be given the option of continuing or abandoning changes. B. A new function for 1. At the very worst, the key should report on your dependency/conflict status, without exiting. 2. (or some other key) should toggle (or cycle through) the package markings. (In the latter case, it couldn't jump and report any dependency/conflict immediately upon key press.) It should also expand and contract headings (as with the folding editor). C. Mouse option (and even X) 1. Let it optionally run as a gpm client. The mouse could be used to scroll (would scroll bars be appropriate even without the mouse?), expand headings (as with the folding editor), and toggle package markings. 2. Port it to X, with the same functionality as the souped up text based version, but prettier (in some people's eyes). III. General A. Don't call dpkg for packages which don't need attention. 1. This might require a change in the way dselect and dpkg interact. 2. Perhaps dselect will have to become a little smarter, but doesn't it already know what is necessary to determine if a package needs attention. B. Allow a choice between several "recommended install sets". 1. For initial installation, have a minimum/base, standard, and maximum "recommended install sets". 2. Allow for different "recommended install sets" in a section. This is partly taken care of by priority, but it should be more flexible. 3. Allow for user defined "recommended install sets". This would be a boon for those who administer multiple boxes. (Perhaps there could be a way to automate the configuration of multiple machines as well.) Often I go into dselect to find a package whose name I can't quite remember, then view its description and check for dependencies, and finally exit dselect and install the package by hand with dpkg -i. That is just plain silly. Perhaps dselect should be rebuilt from the ground up, and maybe someone is already working on it, but that is not what I propose. I think that it would be possible to take dselect as it is now and clean it up considerably with a moderate amount of effort. Who is currently maintaining dselect, and what projects are underway for its improvement? Is it going to take one inspired individual to rewrite all of dselect, or is this something that can be taken on by a small to mid-size group? Dselect is not only Debian's face to the world, it is also an administrative tool which should be quick, powerful, and convenient for even experienced administrators to use. Unless a group like this is already in place, I propose that we form a working group to initially hash out how dselect should be improved, and then to actual
