Re: Deselect problems.
On Sun, Jan 04, 1998 at 02:43:21PM +1000, adavis@netpci.com 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, hamish@debian.org, hamish@rising.com.au, hmoffatt@mail.com
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
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: