Re: Debian conflicts with FHS on /usr/include/{linux,asm}
*- On 9 Jul, Scott Ellis wrote about "Re: Debian conflicts with FHS on /usr/include/{linux,asm} "
> On Fri, 9 Jul 1999, Brian Servis wrote:
>
>> *- On 9 Jul, Philip Hands wrote about "Re: Debian conflicts with FHS on /usr/include/{linux,asm} "
>> >> > 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.
>> >
>> > So are you suggesting that kernel_image packages should contain the headers
>> > with which the kernel was built ? So that if you installed a new kernel
>> > package, you could guarantee that the headers would match ?
>> >
>> >>From past experience, I'd say that this was a bad idea, because it can make
>> > one's development environment unstable.
>> >
>> > Anyone who is building software that really is kernel version dependent, is
>> > actually helped IMO by the fact that while they're building it, the
>> > -I/usr/src/linux/include that appears on each compilation acts as a mnemonic
>> > for ``This is kernel version dependent software''. This also makes the same
>> > fact clear to anyone who is wondering why they cannot build the same binaries
>> > on a different system.
>> >
>> > People who are building software that isn't very kernel version sensitive can
>> > really do without destroying their development environment, just because
>> > they've installed a new kernel.
>> >
>>
>> Yes, the headers under /usr/include should match the current kernel
>> version installed(using package managment of course). With the increase
>> in software that may need kernel headers, Debian needs to be able to
>> support the few of them that do require kernel headers in the location
>> *set by the standards*(the location may be hardcoded or beyond the scope
>> of a Joe User to change). If an advanced user is developing or
>> installing software on an unstable kernel and needs stable headers they
>> will know how to include the appropriate -I to point to a stable kernel
>> tree.
>>
>> Having an -I/path/to/a/stable/linux/include is IMHO a better mnemonic
>> for ``This is kernel version dependent software''.
>>
>> Don't get me wrong. I understand Debian's decision to have a stable
>> /usr/include. However, I think the idea is being out grown by need
>> the average user to install software that needs the kernel headers from
>> the current kernel.
>
> /usr/doc/libc6/FAQ.Debian.gz
>
> Why does someone feel the need to re-argue this every release? The 2.2.x
> README doesn't even include instructions on doing the symlinks anymore.
>
My orginal post was with regards to the FHS standard which states that
the /usr/include/{linux,asm} directories should be links to the current
kernel headers. If Debian is going to follow the FHS and if Debian is
going to have a different policy on /usr/include/{linux,asm} then there
needs to be an exception written in the policy.
Like I said, I understand the logic behind it. But if Debian wants Joe
User to easily use third party software(that requires the kernel
headers) on Debian then they should perhaps think about following the
standards on things like this that can become a real pain for Joe User
but are easilly worked around for the advanced user. Personaly, I can
deal with it, but there have been a large number of posts on debian-user
lately dealing with this topic.
--
Brian
---------------------------------------------------------------------
Mechanical Engineering servis@purdue.edu
Purdue University http://www.ecn.purdue.edu/~servis
---------------------------------------------------------------------
Reply to: