The nice thing about this is that you can keep kernel headers around in a much smaller format on-disk, while still making them available separately as a package if you want.
A few problems this solves:
1. Neither user nor tool knows specifically how to install the headers for specifically this version of the kernel.
2. Manually installing a header package on e.g. Ubuntu marks it as manually selected, meaning it doesn't get cleaned up with an 'autoremove'; selecting a generic kernel headers package (like linux-headers-4.14-generic or something) means that every time your system auto-updates the kernel package version (which happens by default on, for example, AWS IIRC, and happens a lot) you end up with yet another copy of the kernel headers, and then you blow your I/O budget uninstalling them.
3. It removes one extra step to running e.g. an eBPF program, or building an e.g. out-of-tree kernel module, so make scripts can now start to take advantage of that. For example:
# Get headers
if modprobe kernel_headers; then
<unpack the tgz>
else
<scan through /usr/src, /usr/local/src, etc. for what looks like the right version, or fail>
fi
A few problems this solves:
1. Neither user nor tool knows specifically how to install the headers for specifically this version of the kernel.
2. Manually installing a header package on e.g. Ubuntu marks it as manually selected, meaning it doesn't get cleaned up with an 'autoremove'; selecting a generic kernel headers package (like linux-headers-4.14-generic or something) means that every time your system auto-updates the kernel package version (which happens by default on, for example, AWS IIRC, and happens a lot) you end up with yet another copy of the kernel headers, and then you blow your I/O budget uninstalling them.
3. It removes one extra step to running e.g. an eBPF program, or building an e.g. out-of-tree kernel module, so make scripts can now start to take advantage of that. For example: