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/ ?
Ben Gertzfield <che@debian.org> wrote:
> 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.
Your Joe User isn't going to use VMWare either -- he'll just reboot
to switch oses.
> 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.)
Such software is either for developers only (not your Joe User) or
it is broken.
> 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.
The right thing to do, from the viewpoint of creating a distribution
that a lot of people can use, is to fix the broken software.
The right thing to do, from the viewpoint of people to lazy/busy/etc. to
fix the broken software, is to dump the work on someone else.
VMWare doesn't count -- they're getting paid for the product so it's
not fair to introduce deliberate breakage into Debian. The problems
with sound stuff are a bit more complex, but I think that there are better
options than breaking debian.
For the general case, if something *must* have a version match between
the include files and the running kernel it should by default bail out
with a documentation ref for the case where there's a mismatch. A better
option, from the viewpoint of building a distribution like debian, would
be to build something that detects kernel version at runtime and deals
appropriately -- and yes, this involves some serious work in some cases.
--
Raul
Reply to: