[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

*- On  9 Jul, Philip Hands wrote about "Re: Debian conflicts with FHS on /usr/include/{linux,asm}"
> Ben Gertzfield <che@debian.org> writes:
>> Yes and no. :) There is a default install that assumes #include
>> <linux/whatever> is your current kernel version, and it does
>> not prompt you for a -I to specify. It's not difficult to edit
>> the makefiles by hand and add this, but Joe User is never going
>> to be able to figure this out.
> Well, that's just broken.  If they want to know what kernel version
> you're running, they ought to ask the kernel (uname -r), not make an
> assumption that is not guaranteed to be true.

They do use uname to get the kernel version.  However they also check
to make sure that the kernel headers in /usr/include/{linux,asm} match
that version by looking at version.h.  If they don't then the install
aborts. Why should a software package be expected to have an exception
for Debian when the standards in FHS say that the current kernel headers
should be in /usr/include/{linux,asm}?

> Wanting to build unstable kernels on a system that is running a stable
> kernel is a perfectly sane thing to do, in which case the headers
> won't match, and this is not unique to Debian.
> As someone who was repeatedly bitten by drifting header versions when
> building things like ppp, I would absolutely hate to go back to the
> /usr/include --> /usr/src/linux links.
> Finding that you cannot rebuild a package, that built perfectly
> yesterday, simply because you decided to have a look at the latest
> kernel source, is very depressing.

Any Joe User will expect the correct headers to be in place.  Any user
that is building unstable kernels will know better than to place the
headers where they might cause problems.

Mechanical Engineering                              servis@purdue.edu
Purdue University                   http://www.ecn.purdue.edu/~servis

Reply to: