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

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.


Reply to: