Re: Debian conflicts with FHS on /usr/include/{linux,asm}
- To: Joseph Carter <knghtbrd@debian.org>
- Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, "Sean 'Shaleh' Perry" <shaleh@varesearch.com>, fhs-discuss@ucsd.edu, debian-policy@lists.debian.org, quinlan@transmeta.com, t.sippel-dau@ic.ac.uk, moth@magenta.com
- Subject: Re: Debian conflicts with FHS on /usr/include/{linux,asm}
- From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
- Date: Wed, 14 Jul 1999 04:36:49 -0400
- Message-id: <[🔎] 199907140836.EAA00361@tsx-prime.MIT.EDU>
- In-reply-to: Joseph Carter's message of Tue, 13 Jul 1999 10:15:42 -0700, <[🔎] 19990713101541.D489@debian.org>
Date: Tue, 13 Jul 1999 10:15:42 -0700
From: Joseph Carter <knghtbrd@debian.org>
> 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.
I apologize for using the word "hacks". However, I was referring to the
following message from Sean Perry:
>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>.
make-kpkg is very clearly a Debian-specific mechanism. I have no idea
what it does, or how it works. I'm not going to support something which
is Debian-specific. Sorry. If in the context of the Linux Standard
Base there is a standardized way of determining which kernel sources
should be used when compiling modules, and it gets significant actual
usage, that's great. Historically, de facto, this mechanism has been
"/usr/src/linux",
Allowing the user to specify the headers to include just makes sense.
If your software does not allow this, I consider your software
broken.
I certainly allow this. However, I consider a distribution which forces
a user to specify where the kernel headers are, by breaking the
above-mentioned historical convention of /usr/src/linux to be terminally
broken. Naive users won't know how to specify where the kernel sources
are. I want someone's Grand-Aunt Tillie to be able to compile and
install a kernel source module package, no matter which distribution she
might be using.
This is why it's critical why for a naive user who isn't doing kernel
development, and isn't compiling their own kernel, /usr/src/linux needs
to point to the default kernel. It has in the past, historically ---
why break this now?
- Ted
Reply to: