[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel headers---FAQ

On Sat, 17 Jan 1998, Avery Pennarun wrote:

> > you're running a debian system. what is so difficult about
> > acknowledging that and slightly modifying your procedure for working
> > with kernel sources?
> [...shell commands removed...]
> That is, in fact, exactly what I'm doing at the moment.  What I am
> arguing is that there is ABSOLUTELY NO REASON that I should have to
> unpack the kernel in any kind of special way.

why not? debian is used by many more people than just you, and debian's
solution to the kernel/libc headers problem is a general one that
provides the most benefit to the most people, while causing only trivial
inconvenience for people who want/need to do it differently.

using a distribution based around a package manager provides enormous
benefits, but in return requires a slightly more disciplined approach to
managing the system if you want to make use of all of those benefits. if
that price is too high for you then don't pay it...nobody is forcing you

> Further, while it's not difficult to do, most users won't know to do it
> until AFTER they've shlocked their system by unpacking a kernel into the
> already-symlinked /usr/src/linux, or converted their libc6-dev installation
> into an unworkable mess due to a failed installation of kernel-headers. 

neither of these occurences are particularly disastrous and both are
easy enough to recover from. less than 5 minutes work with mv, ln, and
dpkg will restore the system to the state it should be in.

> To reiterate what I and others have said:
> - unpacking the kernel into /usr/src/linux breaks exactly one thing:
>   the kernel-headers install script, which works perfectly and then
>   returns a non-zero exit status because it can't symlink to
>   /usr/src/linux.  This means that kernel-headers can never change to the
>   "installed" state in dpkg, and that's why I have to --force packages not
>   to depend on kernel-headers.  Since kernel-headers really _IS_ installed,
>   these --force'd packages work flawlessly.  I develop kernel modules and
>   large applications: I know when libc6-dev isn't working.

Q.  it hurts when i do this.

A.  don't do that then.

> - No one will ever read the Debian-specific documentation because
>   there is lots of other documentation around (HOWTO's etc) which
>   directly contradict it.

If i'm running Slackware, i read the HOWTOs etc as general linux
documentation and any slackware docs as specific docs for my

If i'm running Redhat, i read the HOWTOs etc as general linux
documentation and any Redhat docs as specific docs for my distribution.

If i'm running Debian, i read the HOWTOs etc as general linux
documentation and any Debian docs as specific docs for my distribution.

If i don't do that then i am stupid and have no cause for complaint if i
screw up my system.

translation of these generic docs to local conditions and conventions is
ALWAYS necessary no matter what distribution you are running.

> - kernel-header's insistence upon installing the /usr/src/linux symlink is
>   arbitrary and unnecessary.  I don't care if it wants to create a symlink
>   to /usr/src/linux if the symlink/directory doesn't already exist, but it's
>   completely pointless to require the link:  it only breaks things.

i don't know whether that link is needed or not. but i've seen enough of
manoj's work to know that i'd trust his opinion on that question.

if i ever needed to over-ride the default behaviour for kernel-package
(or any other package) on any given system then i'd just over-ride it
and make a note in my logbook stating WHAT, WHY, and WHEN.

I wouldn't insist that my local change becomes the new standard for
every debian system built.

> My apologies if I sound angry.  I feel like I'm talking to a void.

maybe you are. maybe everyone else here likes it the way it is and
thinks that manoj has done a great job with kernel-package.

if you want a maintainer to change the way their package does something,
you don't do it by jumping in flaming the package and the maintainer.
you do it by making reasonable and polite suggestions - if the
maintainer doesn't like your suggestions, then take the sources for
kernel-package and roll your own.


craig sanders

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: