Daniel Jacobowitz wrote:
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?
Imagine you have an application using IOCTL system call (or any (2) system call that goes almost directly into the kernel) with the wrong #define or the wrong data structure size, this will also corrupt your application in ways that will be hard to fix. It happened to me a good 30th of times. With up-to-date kernel include, It will not happen. Of course you can *indeed* find examples the other way round but there is no 100% safe solution except recompiling your libc for your kernel each time which is not someting you or I want to do for each pre... I found more example where changing the includes solved my problems than examples were it actually broke something. I guess your experience is different .
Often using -I is not really sufficient to detect errors because a program can include a files that do no more exist or do no more contain a type definition in the up-to-date kernel includes but that will be included if you do not specify -nostdincl. Note that in that case, patching the includes does not always help...
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.
NPTL is fine mostly for servers. But I guess a number of user mode driver for average people will also probably break right now because of API inconsistencies between 2.4 and 2.6 (raw 1394 or USB are expected). I start wondering if a 2.4 GLIBC and a 2.6 GLIBC should be envisaged?
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.
Anyway thanks for your patience and the discussion. -- __ / ` Eric Valette /-- __ o _. 6 rue Paul Le Flem (___, / (_(_(__ 35740 Pace Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76 E-mail: eric.valette@free.fr