Bug#218516: linux-kernel-headers: Check for symbolic link before installing
On Sun, Nov 02, 2003 at 10:24:09AM +0100, Eric Valette wrote:
> Daniel Jacobowitz wrote:
> >On Sat, Nov 01, 2003 at 10:23:09PM +0100, Eric Valette wrote:
> >
> >>Daniel Jacobowitz wrote:
> >>
> >>
> >>>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.
> >>
> >>Come on, read the LKML and everybody there seems to agree that *only*
> >>sanitised kernel headers should be used and not the plain kernel headers
> >>because only few data structure definition and constants are really
> >>requiered to compile any ANSI applications. There are already some bug
> >>reports, expects others or at least let people do things by checking
> >>*needed* symbolic links...
> >
> >
> >What does this have to do with your problem?
>
> Just the tone and the *come on* of your previous answer that seems to
> imply, what you have done is obvious and perfect. I have been compiling
> and using application and user mode drivers for years patching the
> includes to get accurate kernel data structure and API definitions. This
> does *of course* not break debian compiled application and sometimes
> saved my ass when libc-dev includes were innacurate.
>
> So my request is to include the *asm-generic symbolic link check* as
> 1) it doesn't hurt people following the standart way
> 2) but will avoid many errors to people that have been doing the
> includes tricks for good reasons for years.
Sorry, Eric. However, I've been patching up inexcplicable errors from
people who preferred to mismatch headers this way. Also for years.
Why is adding the extra -I instead of messing with what the rest of
your Debian system expects such a burden?
>
> >Of course we need sanitized kernel headers. No one's _written_ an
> >adequate set yet. Until that happens this is what we need to do.
>
> Why 2.6 kernel headers when official debian install kernel is hardly 2.4?
Because Sarge supports NPTL when using 2.6 kernels, and that requires
2.6 headers to be useful. A number of other applications can take
advantage of 2.6 features there now.
> >Adding symlinks to point at your current kernel version is even less
> >sanitized than using what we provide.
>
> At least I have 2.4 includes and data structures :-) For me having a
> wrong data structure for user mode drivers is far worse than having a
> wrong GLIBC for some recompiled by hand applications...
>
> And by the way, I find providing the kernel headers used to compile the
> LIBC necessary but just do not want it to corrupt possible existing
> symbolic links. You already do some checks, do one more.
The existing preinst checks are for cleaning up packaging bugs in an
old version of glibc; we can't sanity check the users' system for them.
But I'll add it next upload.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: