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
changes.
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: