Re: Debian conflicts with FHS on /usr/include/{linux,asm}
>>>>> "Raul" == Raul Miller <rdm@test.legislate.com> writes:
Raul> VMWare I know nothing about. Are you supposed to recompile
Raul> it every time you change kernel versions? And does it
Raul> really not let you specify -I/usr/local/src/linux/include/ ?
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.
Raul> Anyways, two examples is hardly "tons of software".
No, but there's also the myriad of software that uses kernel headers
for audio data structures (like awe32 software) and for less
legitimate reasons (mostly exploit software that uses raw packets)
that isn't very happy with out-of-date kernel headers like ours.
(By out-of-date I mean not matching the running kernel.)
Raul> Anyways, there's nothing about the existence of that symlink
Raul> that really fixes such software. It's the "implied
Raul> guarantee" that the headers are the same version as the
Raul> running kernel that's the issue.
Raul> And software which requires that, to be built, is going to
Raul> cause a lot more problems in the long run -- breaking Debian
Raul> isn't going to fix that.
These are both completely true. I just wish there were a better way
for Debian to support the user maintaining /usr/src/linux and
/usr/include/{linux,asm} on their own, rather than forcing them
to remove directories or have a knowledge of (the rather esoteric)
dpkg-divert and friends.
--
Brought to you by the letters G and I and the number 1.
"Atatakaku natta kara, otaku to uchi no kazoku de, nani ka shimasen ka?"
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
Reply to: