Markos Chandras posted on Thu, 21 Feb 2013 21:25:30 +0000 as excerpted: >>> Eg. bug #458014. >>> >>> Any ideas about how to deal cleanly with situations like that? >>> >>> >> I'm no expert, but I always thought that modules are supposed to >> consume headers from the kernel source directory, not from >> /usr/include/linux.
I believe I've read that somewhere quite authoritative (like LWN) as well. Kernel modules, kernel sources. Userspace, the cleaned up Linux- headers. In fact, there has been quite some kernel work recently (3.7 I believe, the commit log was heavy with related commits) done in ordered to make the separation cleaner. >> As well, the modules should be installed for whatever kernel version is >> present in /usr/src/linux (or KERNEL_DIR. This may be distinct from the >> currently running kernel. This problem is much worse with gentoo than with a typical binary distro that much more strictly controls both the kernel and headers shipped. AFAIK, that's one of the major reasons the eclass is there, to semi- standardize both the handling and the relative priority of the various possibilities, but no solution's going to hit every corner-case, and if something's breaking on specific user's systems, in the end it's them that may have to either standardize their system (and build practices) to some degree, or handle their own breakage if they choose not to. But userspace definitely should be using the installed linux-headers. And in-treeing kernel modules is STRONGLY encouraged upstream exactly due to this and other issues, to the point that while out-of-tree modules are tolerated as a fact of life, they're very much on a "the responsible dev (and users who choose to use his code) gets to keep his pieces" policy. That being the upstream policy, there's definitely limits on what gentoo can do to unbreak what upstream has already declared broken, too. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
