Re: kernel-headers-2.0.32 vs. kernel-headers-2.0.33

[Ngo Bach Long <bach@pc3.eecg.utoronto.ca>]

> >       Nothing but libc6-dev is supposed to set symlinks in
> >  /usr/include; certainly the kernel packages should not.
> >
>    
> YES they SHOULD!  If the /usr/include symlinks are pointed to
> /usr/src/kernel-headers-2.0.29 and you install kernel-source-2.0.32 you
> MUST change those symlinks to point to /usr/src/linux-2.0.32/include/...

Take a look at /usr/doc/kernel-source-2.0.33/README.headers.gz

It explains the new (currently Debian-specific) policy for kernel 
include files.

Some excerpts:

>                 Kernel Headers and libc6-dev package
>                 ====================================
>
>                                 [...]
>
>                   Traditional two symlink approach
>                   =========== === ======= ========          
>
> Under libc5, it was standard for part of the user interface to 
> libc to be exported from the kernel includes, via /usr/include/linux
> and /usr/include/asm.  Traditionally, this was done by linking those
> two directories to the appropriate directories in
> /usr/src/linux/include.  This is the method documented in the install
> instructions for the kernel sources, even today.
>
>                           Why that is bad
>                           === ==== == ===
>
>                              [...]
>
>                        Debian's libc6 method
>                        ======== ===== ======
> [...] The variation is that we link to header files from
> a specific kernel version, namely 2.0.32, which are the headers that
> libc was compiled with. Whereas we used to link to any old kernel in
> the original libc5 symlink, the new libc6 symlink is to
> /usr/src/linux-2.0.32, which is a symbolic link that holds headers
> from a *static, well known*, *supported*, tested kernel version, and
> we let the kernel-headers package handle architecture dependencies
> (which it had to anyway).
>
> [...]
>
> This is a working technical solution to having libc
> development package contain/depend on a well known static set of
> kernel headers (insulating the vast majority of programs that are not
> closely tied to kernel version specific internal data structures),
> while allowing the kernel headers to vary from architecture to 
> architecture, and still allowing device driver authors from having
> any set of kernel headers they want on the machine through the simple
> artifice of adding a -I flag to the compilation flags.
>

So I believe the Makefile for kernel-source-2.0.33 will include the
correct kernel headers using the -I option.


--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org