Re: Debian conflicts with FHS on /usr/include/{linux,asm}

["Theodore Y. Ts'o" <tytso@mit.edu>]

   Date: Mon, 12 Jul 1999 15:54:10 -0700 (PDT)
   From: "Sean 'Shaleh' Perry" <shaleh@varesearch.com>

   Debian currently uses a system where one needs the kernel source to
   compile a modules (like pcmcia) but can compile ANY version of the
   kernel and pcmcia.  make-kpkg looks in the current dir, assumes it to
   be 'linux' and then steps back into .. and looks for modules.  It
   then builds in there using -I<path I came from>.

Well, I distribute the Comtrol Rocketport drivers assuming that
/usr/src/linux contains the sources to the default installed kernel for
the naive user.  

I don't intend to support Debian specific packaging hacks that only work
for Debian, and I suspect that other hardware manufacturers that are
enlightened enough to distribute drivers which are kernel modules in
source form for their products will have a similar reaction --- the
market is too small to justify spending a lot of engineering time to
support a very distribution-specific build system.

   Date: Tue, 13 Jul 1999 09:16:09 +0200
   From: Andreas Jellinghaus <aj@dungeon.inka.de>

   hmm. guess everyone has at least two different kernels (old working one and
   new compiled one). but there can be only one /usr/include/...

The Rocketport drivers allow someone who can modify the Makefile to
change /usr/src/linux to some other value to support more than one
kernel.

But I need to be able to support naive users that use whatever kernel
that came with their distribution, and who aren't comfortable modifying
Makefiles or compiling their own kernel.  In the case of Comtrol
Rocketports, these are typically scientists/researchers who purchased a
Rocketport because they needed a large number of serial ports to control
their data acquisition equipment.  They are *not* interested in hacking
kernels, and they don't want to modify Makefiles to change a -I flag.


My worst-case nightmare is that the FHS starts encouraging distributions
to make the same mistake Slackware did, which was to distribute
completely mismatching kernel header files and kernels.  Since building
kernel modules require that header files match exactly (think
/usr/include/linux/modversions.h), that means that I would have to tell
naive, non-developer users that they first have to:

	1)  download kernel sources from ftp.kernel.org,
	2)  configure a kernel to match their hardware configuration, 
	3)  build their own kernel
	4)  install their own kernel, and only then can they 
	5)  build my device driver

I hope people can understand why this would be a complete non-starter
for a certain class of users, and why I might refuse to support my a
kernel module on any distribution that made such a user-hostile design
decision....

							- Ted