Bug#218516: linux-kernel-headers: Check for symbolic link before installing
On Sat, Nov 01, 2003 at 10:13:57AM +0100, Eric Valette wrote:
> Daniel Jacobowitz wrote:
>
> >It's not just arguably a mistake, it's terrible abuse of the Debian
> >package manager. DO NOT overwrite something owned by a package without
> >using dpkg-divert. Dpkg can't protect users from themselves.
>
> OK but people are use to just DO that because of the need to include
> up-to-date API for some drivers in user mode (e. 1394raw, USB, ...). I
> think the symbolic check you mention below, just highlight this.
>
> The fact that they are now 2.6 kernel include may make the problem just
> worse as many user are still runing 2.4 as some user land driver API are
> either less or more up-to-date in 2.6 than in 2.4.
>
> On one hand, you force the installation of the kernel headers but say
> that they should not be used and indeed, they contain some API that are
> wrong depending on your real kernel. I understand you need to provide
> the headers used to compile the libc in case someone want to recompile
> it but why do you force the installation rather that providing a pseudo
> package that really install the current kernel headers :
>
> #!/bin/bash
> # set -x
> WHO=`whoami`
> if [ "$WHO" != "root" ]
> then
> echo "You must be root to perform include update"
> exit 1
> fi
> for i in linux asm asm-generic scsi
> do
> if [ ! -h /usr/include/$i ]
> then
> echo "Updating /usr/include/$i"
> rm -rf /usr/include/$i
> cd /usr/include; ln -s /usr/src/linux/include/$i .
> fi
> done
>
> I use this script to have up-to-date correct kernel includes and it
> contains asm-generic directory...
Come on, there are a dozen FAQs explaining this. The kernel headers
used to compile user space applications MUST MATCH THE HEADERS THAT
GLIBC WAS COMPILED AGAINST. Period. If you want to compile
applications against a different set of kernel headers use -I at your
own risk.
Many glibc headers reference kernel headers for definitions or data
types.
> ># Old versions of glibc installed these symlinks. Remove them
> ># if they exist.
> >if [ -L /usr/include/asm ] ; then rm -f /usr/include/asm ; fi
> >if [ -L /usr/include/linux ] ; then rm -f /usr/include/linux ; fi
> >if [ -L /usr/include/scsi ] ; then rm -f /usr/include/scsi ; fi
> >
> >Did that not happen?
>
> You are missing the *asm-generic* link that's the reason.
Because old glibc's never installed an asm-generic. So it wasn't and
isn't necessary.
> I did not really investigated what went wrong but :
> - I compiled pre9 two days ago on my desktop (before the
> installation of the linux-kernel-header package. Everything compiled fine,
> - I then updated my *laptop* including the headers and *then* tried
> to compile pre9 as it contains ACPI fixes. Compilation failed because of
> non homogeneous interfaces (tlb.h now includes asm-generic/tlb.h) and
> depending on the version this includes asm/tlbflush.h that does not
> exist on 2.4,
> - As I remebered the kernel-header packages, I just removed
> /usr/include (asm|scsi| linux) by hand, reinstalled the kernel
> sources, and reinstalled the kernel headers and everything went fine.
> - I then got back on my desktop and tried the compilation to see if
> things had also been screwed and indeed I got the same error.
>
> So at least include asm-generic in your symbolic link check...
The check is designed to work around an old dpkg limitation and a bad
decision in earlier glibc packages. It's not designed to accomodate
people ignoring the advice not to use symlinks to a kernel in
/usr/include.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: