Re: Debian conflicts with FHS on /usr/include/{linux,asm}
Date: Tue, 13 Jul 1999 17:49:56 -0700
From: Joey Hess <joey@kitenet.net>
Ted, I resent your attitude, whatsmore, you are sadly out of date on this
issue, which was new two full years ago and is now very old news. The way
debian does this is the correct way according to Matthias Ulrich and it also
has Linus's blessing:
Joey,
If you look at Linus's rationale, he's talking about **user**
space programs not depending on the kernel header files. This is a very
big difference when compared with ***kernel modules***, which absolutely
need to be able to access silly, stupid things like
<linux/modverions.h>, and absoluetely needs access to kernel structures,
since they are going to be linked with the kernel. This is a
fundamental technical requirement.
What part of this do you not understand?
So for kernel modules, which is what I was specifically talking
about, we absolutely **must** have access to /usr/include/linux and
/usr/include/asm. Linus has said that he doesn't like user-space
programs referring to /usr/include/linux, but he also said that he
wasn't speaking "ex-cathedra" manner on this issue. But his reasoning
absolutely doesn't apply to stand-alone kernel space modules.
I repeat --- I will not support the Comtrol Rocketport driver as
a stand-alone kernel module --- or any stand-alone kernel module for
that matter --- on a distribution where there isn't a way for the
distribution to be able to automatically find the kernel-specific header
files to be able to compile the stand-alone kernel-module. I simply
don't have the bandwidth to handle all of the dazed and confused users
will won't be able to compile the kernel module on that distribution.
Now, if Debian is willing to say that they don't support naive
users, then this might be a rational decision. But if you want it to
support naive users, then, like your (IMHO) naive-user-hostile
installation process, I encourage you to rethink your position.
- Ted
Reply to: