Deselect problems.
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 adavis@netpci.com
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
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: