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

Re: What's Debian's /usr/src policy

martin@debian.org (Martin Mitchell)  wrote on 06.01.98 in <8790strcyu.fsf@mail.usyd.edu.au>:

> kaih@khms.westfalen.de (Kai Henningsen) writes:
> > martin@debian.org (Martin Mitchell)  wrote on 06.01.98 in
> > <87iuryqjzn.fsf@mail.usyd.edu.au>:
> >
> > > Stephen Zander <srz@mckesson.com> writes:
> > >
> > > > Martin Mitchell <martin@debian.org> writes:
> > > > > Ian Jackson <ian@chiark.greenend.org.uk> writes:
> > > > > > Why does libc6 depend on kernel-header ?
> > > > >
> > > > > It's libc6-dev that has that dependency.
> > > > > Perhaps weakening the dependency to Suggests might be the best
> > > > > solution.
> > > >
> > > > No, you can't.  Their are multiple header files that will be flat
> > > > *broken* without a /usr/include/{linux,asm}.
> > >
> > > I know, however it would allow people to much more easily install and
> > > maintain their own kernel sources for these includes.
> >
> > Which is why we shouldn't do that. Remember, we *DO NOT* want them to
> > include their own kernel sources for these includes, because it is a *VERY
> > BAD IDEA*.
> Rubbish, it's essential for almost all architectures except i386 and alpha,
> that are not yet integrated with the main kernel source.

Complete and utter bullshit.

The "we really need specific headers" thing is true for _all_  
architectures; the reasons are completely independant of architecture.

Where to get those specific headers - that is, which patches to apply -  
might differ between architectures, but the principle is the same:

/usr/doc/libc6-dev/FAQ.Debian.gz (this one is from the previous version):

Q1: Why does Debian provide kernel headers with the libc6-dev package
instead of using the standard Linux convention of having symlinks to
the currently installed kernel?

A1: Manoj Srivastava explains why (this was originally for libc5, but
is still valid for libc6):

> From: Manoj Srivastava <srivasta@pilgrim.umass.edu>
> 	The headers were included in libc5-dev after a rash of very
>  buggy alpha kernel releases (1.3.7* or something like that) that
>  proceeded to break compilations, etc.  Kernel versions are changed
>  far more rapidly than libc is, and there are higer chances that
>  people install a custom kernel than they install custom libc.
> 	Add to that the fact that few programs really need the more
>  volatile elements of the header files (that is, things that really
>  change from kernel version to kernel version), [before you reject
>  this, consider: programs compiled on one kernel version usually work
>  on other kernels].
> 	So, it makes sense that a set of headers be provided from a
>  known good kernel version, and that is sufficient for compiling most
>  programs, (it also makes the compile time environments for programs
>  on debian machines a well known one, easing the process of dealing
>  with problem reports), the few programs that really depend on cutting
>  edge kernel data structures may just use -I/usr/src/linux/include
>  (provided that kernel-headers or kernel-source exists on the system).
> 	libc5-deb is uploaded frequently enough that it never lags too
>  far behind the latest released kernel.
> 	I hope I was clear enough to answer your question.
> 	manoj

There's also a message from Linus somewhere which explicitely agrees with  
that point of view.

MfG Kai

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: