Re: Deselect problems.
On Sun, 4 Jan 1998, Hamish Moffatt wrote: 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. The kernel-source-2.0.32 deb has a 130K diff file against the standard source. Just where do these patches come from and why are they necessary? Is the fact that I _have_ to have 2.0.32 source or headers going to stop me from going to 2.0.33? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lindsay Allen [EMAIL PROTECTED] Perth, Western Australia voice +61 8 9316 248632.0125S 115.8445Evk6lj Debian Unix =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Deselect problems.
Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, Jan 05, 1998 at 08:59:50AM +0800, Lindsay Allen wrote: The kernel-source-2.0.32 deb has a 130K diff file against the standard source. Just where do these patches come from and why are they necessary? Is the fact that I _have_ to have 2.0.32 source or headers going to stop me from going to 2.0.33? I don't know why all those patches are already applied. I have stopped using the kernel-source packages because they can't be patched up to the next kernel version easily (because of the already applied patches). You should be able to install kernel-headers to satisfy it and then dump the standard Linux source tree in for building kernels. Does anyone know why there is a dependency on kernel-headers? I was under the impression that glibc didn't use the kernel headers. Steve [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Deselect problems.
Steve Dunham [EMAIL PROTECTED] writes: SD Hamish Moffatt [EMAIL PROTECTED] writes: HM On Mon, Jan 05, 1998 at 08:59:50AM +0800, Lindsay Allen wrote: LA The kernel-source-2.0.32 deb has a 130K diff file against the LA standard source. Just where do these patches come from and why LA are they necessary? Is the fact that I _have_ to have 2.0.32 LA source or headers going to stop me from going to 2.0.33? HM HM I don't know why all those patches are already applied. I have HM stopped using the kernel-source packages because they can't be HM patched up to the next kernel version easily (because of the HM already applied patches). You should be able to install HM kernel-headers to satisfy it and then dump the standard Linux HM source tree in for building kernels. SD SD Does anyone know why there is a dependency on kernel-headers? I SD was under the impression that glibc didn't use the kernel headers. ...or why it depends on kernel-headers-2.0.32 instead of just kernel-headers, which is provided by the kernel-source-* and kernel-headers-* packages? -- _ / \ The cat's been in the box for over | David Maze | 20 years. Nobody's feeding it. The | [EMAIL PROTECTED] |cat is dead. | http://donut.mit.edu/dmaze/ | -- Grant, on Schroedinger's Cat \_/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Deselect problems.
On 5 Jan 1998, Steve Dunham wrote: Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, Jan 05, 1998 at 08:59:50AM +0800, Lindsay Allen wrote: The kernel-source-2.0.32 deb has a 130K diff file against the standard source. Just where do these patches come from and why are they necessary? Is the fact that I _have_ to have 2.0.32 source or headers going to stop me from going to 2.0.33? I don't know why all those patches are already applied. I have stopped using the kernel-source packages because they can't be patched up to the next kernel version easily (because of the already applied patches). You should be able to install kernel-headers to satisfy it and then dump the standard Linux source tree in for building kernels. Does anyone know why there is a dependency on kernel-headers? I was under the impression that glibc didn't use the kernel headers. The libc6-dev package used to include its own copy of the linux and asm directories from the kernel source. The libc6 maintainer decided that it was rather pointless to make a hude diff that was essentially just the kernel-headers package, so the dependancy was added again. It is for a version-specific package for the reasons given in /usr/doc/libc6/FAQ.Debian.gz -- Scott K. Ellis [EMAIL PROTECTED] http://www.gate.net/~storm/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
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[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 SaganGMT+10 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Deselect problems.
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] .
