On Tue, Jul 13, 1999 at 05:15:16AM -0400, Theodore Y. Ts'o wrote:
> 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.
I think that is at the very least extremely impolite of you to say in the
manner you just did. Especially given that the "hacks" Debian uses work
for everybody. Allowing the user to specify the headers to include just
makes sense. If your software does not allow this, I consider your
software broken. And if you are unwilling to take into consideration that
someone might want or need to specify a kernel include directory, I think
it reflects extremely badly on you as a coder.
I'm not saying you should be going out of your way to support something
60% of your users will never need. However the above paragraph looks more
like a refusal to support a technically superior solution AT ALL because
the average idiot would never figure it out if their distribution couldn't
do it for them.
KGIcon also does not support the way Debian does things directly. Not a
problem, the directory for the kernel tree was at least configurable (not
well documented but it was there) so all I had to do was override the
default in a buried include file for a Makefile. This was not a problem
and I was happy to make the change.
Had it been a more complex change requiring something that would be
unreasonable to simply override on a command line or write a simple patch
that I am sure would apply cleanly for some time to come, I'd have
submitted a patch which added the ability without breaking the defaults.
If that were not accepted simply because a simple majority wouldn't ever
really need it, I'd be kinda annoyed.
Being able to tell some software that relies on the kernel to run which
kernel it should look at when it's compiling is not a Debian-only idea.
It's fine to assume the one you want is the one you're running if you can
change the default, especially if /usr/src/linux happens to be the same
version uname reports.
Personally I think /usr/src/linux should GO AWAY. Every sysadmin worth
their salt uses /usr/src/linux-version or similar with a symlink pointing
back for compatibility. It's only common sense that you don't throw away
the old software until you've tested the new--especially at the system and
kernel levels.
--
Joseph Carter <knghtbrd@debian.org> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE
--------------------------------------------------------------------------
<MFGolfBal> rit/ara: There's something really demented about UNIX
underwear...
Attachment:
pgpGhELLfVxh4.pgp
Description: PGP signature