I have never given dselect a "fair" shakedown, because every time I have tried it I have immediately gotten in trouble. Yesterday and today I have decided to carry out the process to its conclusion. I've gotten in trouble again. I wonder if other people are beyond these problems; I am amazed not to see more questions on the net, after the experience I am having.
I'd like to comment. Dselect goes berzerk when I chose to allow it to remove packages. It isn't apparently following my advice. I spent three to four hours trying to get all the way through the list, but when trying to override "suggestions" I have gotten into trouble a few times---dselect doesn't want to believe my overrides, and goes right back and tries to do the same thing all over again. Dselect botched up the various perl packages so badly that dselect itself couldn't run properly. I had to reinstall all those packages by hand before the login script would work. Files I hadn't at all specified were deleted. I can't offer much in the way of constructive criticism. When running through the selection process, both gs-aladdin and the kernel source and headers come up again and again. If overridden once, they pop up again whenever there is a doubt. Selecting packages becomes a dizzying process. Gs-aladdin isn't recognized, apparently, as an alternative to gs: it was twice removed, and twice reinstalled, together with gv. The kernel source and kernel headers thing is especially troubling. Numerous times, the same knot comes up, even when I attempt to override. When I successfully override the "suggestion" to install kernel headers and kernel source, dselect can't accept it. Can't developers accept that some users---I'm reasonably sure I'm not the only one---want to do kernel compiles and headers the standard way? Can't you make it a nice enhancement (for those who chose it) rather than building those kludges into the system so insidiously that it becomes double the trouble to try to do things that standard way (yes I have read that FAQ's). Everything having happened so suddenly, how can I find out what packages were merrily removed by dpkg, short of these occasional surprises that are now punctuating my life? It would be more than courteous to remind the use what was removed after it's all happened; it would be better still if the removal was interactive. Progress reports would be nice for other actions as well. I have had trouble compiling a number of things on my system, and with the proliferation/fragmentation of libraries (in a vacuum of documentation or indications of what goes with what) I haven't been sure what I really need to have on the system, or what I need to keep up to date. The debian packaging system is extremely helpful inthis way, but it is offset by this fragmentation that has become almost ridiculously hard to keep up with. Perhaps dselect or it's ilk could check for a standard development setup, what might be wrong, what might be right with it. Or, for example, networking. A checkup, looking for obvious problems, depending on what the user wants or needs. I think that such tools are probably going to be more useful somewhere down the line, when the dust has settled a bit. I'm now in my third (and last) try. I've about run out of time. Alan -- "Our loyalties are to the species and the Alan E. Davis planet. We speak for Earth. Our [EMAIL PROTECTED] obligation to survive is owed not just to Marianas High School ourselves but also to that Cosmos, ancient AAA196, Box 10001 and vast, from which we spring." Saipan, MP 96950 Northern Mariana Islands ---Carl Sagan GMT+10 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .