On Sun, Jan 04, 1998 at 02:43:21PM +1000, [EMAIL PROTECTED] wrote: > 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.
If dselect, doesn't let you move on easily, then they're probably not suggestions, they're recommendations. You have to hit Q to ignore recommendations. Or they might be dependencies; if that's the case, things WILL break when you tell it to remove them anyway. (In fact, dselect won't actually be able to remove them -- dpkg won't do it). > 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. Are you sure you haven't forced anything? > 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). There is absolutely no necessity to have a kernel-source or kernel-headers package on your system (that I'm aware of). You can certainly dump your own copy of the Linux source tree into /usr/src/linux, compile it (with or without kernel-package/make-kpkg) and install it. dpkg/dselect won't care. I never use the source packages because I don't like the way they're already patched with some non-standard things in some cases. (Actually, the latest libc6{-dev} does require you to install kernel-headers. Are you running that?) If you're complaining about the lack of symlinks from /usr/include/linux to /usr/src/linux/include, can you supply three really good reasons why you need them? Any good kernel-specific software knows that it has to look in /usr/src/linux/include for the headers, not /usr/include/linux. The kernel itself ignores /usr/include/linux. I know ftape for example (which compiles as a module and is therefore kernel specific) knows to look in /usr/src/linux/include. > 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. Debian 2.0 might have some pre-defined installation types, but after the system is installed, dpkg will ensure that all the dependencies are met, ie that any piece of software installed has all the other pieces of software it needs also installed. But if you force anything with dpkg and dselect, you're on your own. hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .