linuxPackages: remove kernelHeaders #14784
Conversation
joachifm
changed the title
|
Well, the API does change in the sense that new kernel versions can add new stuff. Say, if I right now wanted to use say, However, that does have the drawback that if the 4.4 kernel in nixpkgs gets stable/security updates, my program would need to be recompiled for no good reason... so really only suitable for lazy people and/or out-of-nixpkgs packages, I'd guess. The "proper" way would be add a |
|
When I say patching I don't mean updating the kernel, I'm aware that could change the API. According to https://www.kernel.org/doc/Documentation/kbuild/headers_install.txt they are always backwards compatible, so it should be okay just use the newest header package. |
Well, yes. But the latest |
Oh, I very much agree with that, but I don't see why we can't update the top-level attribute instead? |
|
Linus on API headers: http://lkml.iu.edu/hypermail/linux/kernel/0007.3/0587.html The way I read this, you always want the API headers that were used for libc, which I think strengthens the argument for removing |
joachifm
added
9.needs: reporter feedback
joachifm
changed the title
|
I have now updated klibc to use linuxHeaders and moved it out of linuxPackages. The reasoning for each step has been consolidated in the commit messages. |
Extracting headers from a grsecurity patched kernel triggers additional build steps that require gcc plugins. For this to work, we'd need to add gmp, libmpfr, and libmpc to the build inputs as well as run `make prepare` before installing the headers (lest the build fail due to missing files). Out-of-tree modules use kernel.dev and user space should use the Linux API headers used to build libc, not headers extracted from random kernels, so fixing this for grsecurity is pointless.
klibc was the only user of kernelHeaders; it should use the Linux API headers, however.
There's no reason for this to be tied to a specific kernel: it is tied to the API headers, not the kernel sources.
User-space programs should not be using headers extracted from random kernels, but should in fact use the headers that were used to build libc; see e.g., this LKML posting by Linus Torvalds on the subject of Linux API headers at [1]. What is more, the Linux API headers are supposed to be backwards compatible[2], so there's really no good reason to have more than one such package, namely the latest one required by a package in our tree. That is, `kernelHeaders` is not only incorrect but serves no real purpose: out-of-tree modules use the sources provided by `kernel.dev`; user space should use `stdenv.cc.libc.linuxHeaders` or the top-level `linuxHeaders` attribute. Apart from klibc, nothing in nixpkgs used `linuxPackages.kernelHeaders`, so the impact of this change is minimal. [1]: http://lkml.iu.edu/hypermail/linux/kernel/0007.3/0587.html [2]: https://www.kernel.org/doc/Documentation/kbuild/headers_install.txt
|
I've successfully built all affected packages locally, so given the lack of objections, I'm merging this. |
EDIT: see commit messages for details