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

Re: GLIBC 2.0.5c changes...



Nikita Schmidt <cetus@snowball.ucd.ie> writes:
> What strikes me is that kernel headers are included in the libc
> development package.

Oy.  Couldn't you have mentioned abortion or gun control?  This is one
of the original hot-button topics for Debian.

> What happened to the package `kernel-headers'?

Still exists, best I know.  It's basically obsolete, though.

> With 2.0.x even non-asm kernel headers are different on different
> hardware platforms.  I may have missed the integration of
> kernel-headers into glibc, but I don't recollect any talks on this
> topic.  Does anybody know how and why it happened?

It happened because David Engel and I did the original creation of
glibc packages, and we both went with what has been Debian policy WRT
libc5 for a couple of years and has been stated as Linus' preferred
way for headers to be distributed---that is, that the latest stable
kernel headers be packaged with libc.

I've cc:'d David on this, BTW, since he's taking back over glibc for
the interim at least (thanks, David, for volunteering before I did).

I suspect he doesn't want to go over this yet again, but I feel I
should at least give him a chance. :-)

> Anyway, I think at the moment we'd be better off with symlinks into
> /usr/src/linux, until we figure out how to make an architecture specific
> kernel-headers package.

It's already being done---we're getting the right kernel headers.
Symlinks are bad, and Linus himself has come out against them.
They're no longer necessary for kernel compilation, and the only thing
resembling a compatability guarantee we get from Linus is for upwards,
not downwards compatability.

So if something gets compiled with the latest development kernel
headers, there's no guarantee that it will interface correctly with
the latest stable kernel.

All of which is pretty much beside the specific issue I was alluding
(badly---I should have been more explicit) to.  Specifically:

When David and I were working on the first couple of iterations of the
glibc package, we made patches to some of the kernel headers that
dealt with some conflicts between glibc and the kernel headers
(something that we couldn't do without having the kernel headers in
the glibc package, BTW), and those seem to have been removed.

Specifically, fd_set is no longer protected correctly---I think most
of the others were dealt with upstream, but this one wasn't.

> Although this approach may break some compilations (requiring simple
> workarounds in kernel headers - I hate it as much as everyone else
> here), it ensures that we interface with the kernel correctly.

No, it doesn't.

What if you're running a 2.1 kernel and I'm still running 2.0.31?
libc should include the headers from the latest mainstream
kernel---which is generally the latest stable kernel, although I
wouldn't think it totally impossible for them to reflect a
particularly common and stable late-model development kernel.

> Mike, where are your /usr/include/{linux,asm,scsi} from?

libc6.1.

Mike.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: