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

Re: Debian Specialities (fwd)

clameter@waterf.org (Christoph Lameter)  wrote on 02.01.97 in <[🔎] Pine.LNX.3.95.970102193810.19383A-100000@waterf.org>:

> On 2 Jan 1997, Manoj Srivastava wrote:
> srivasta >	I mean, if the run time kernel api/data structures are
> srivasta > irrelevant, how does it matter if you compile with the headers
> srivasta > belonging to the kernel source you happen to have on your
> machine, as srivasta > opposed to the headers packaged by the libc
> developer? Are the srivasta > reasons technical, or aesthetic?
> The issue is really not there in the 2.0.X or 1.2.X Versions since the
> kernel interface is (supposed to be) stable. But
> whenever we enter an development cycle like 1.3.X and 2.1.X then the
> kernel interface becomes volatile. The longer the stable version is
> out the more people will be using the unstable version and the more
> problematic the issue becomes.

Those are exactly the situations where you should *not* rely on /usr/ 
includes/linux. You are building kernel version dependent stuff; kernel  
versions on machines in these development phases will _often_ change from  
boot to boot, but a /usr/include/linux symlink will not follow these  

You cannot use this for the case where you would want it the most. The  
whole idea is severely broken.

If you are doing kernel-version-related stuff, ask which kernel source  
tree you should use. It is, of course, always preferrable to do something  
that makes you binary compatible with most kernels; for that, you either  
need the sources of a specific kernel (the newest you know how to handle),  
or any will do (depending on what type of problem this is).

But you can't rely on /usr/include/linux to provide that information,  
because it often doesn't, even on non-Debian machines.


In any case, the important thing for Debian is to get it right for most  
people, most of the time. By this measure, compiling kernel version  
dependant stuff is far down the list; stable headers for portable programs  
are fairly high on the list. This means that /usr/include/linux should  
match *exactly* what the current libc5 was compiled with, and should be as  
bug-free as possible.

Most people don't compile dosemu, or pcmcia-modules, or other such stuff.  
Don't forget that.

MfG Kai

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com

Reply to: