In Lucid, linux-headers is a virtual package that doesn't seem to have a concrete package associated with it (see http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-relationships.html#s-virtual), which means the linux-headers package is uninstallable on its own. We would then need to do a versioned depends on a particular kernel version (all the more necessary because the socket.h file is located in /usr/src/linux-headers-<kernel version>/include/linux/socket.h, and /usr/include/linux/socket.h is not touched). This has caused problems in the past iirc.
AIUI, the idea behind doing the dynamic generation of this file is to keep the maintenance of it to a minimum. If we Build-Depends on a versioned linux-headers package, we will add a lot of maintenance overhead since we'll need to update the apparmor package every time the kernel has an ABI bump, otherwise it will FTBFS. The other option is a static file, which could conceivably go out of date as easily as the glibc version, or worse stay out of date longer than the glibc version. Am I missing something?
In Lucid, linux-headers is a virtual package that doesn't seem to have a concrete package associated with it (see http:// people. canonical. com/~cjwatson/ ubuntu- policy/ policy. html/ch- relationships. html#s- virtual), which means the linux-headers package is uninstallable on its own. We would then need to do a versioned depends on a particular kernel version (all the more necessary because the socket.h file is located in /usr/src/ linux-headers- <kernel version> /include/ linux/socket. h, and /usr/include/ linux/socket. h is not touched). This has caused problems in the past iirc.
AIUI, the idea behind doing the dynamic generation of this file is to keep the maintenance of it to a minimum. If we Build-Depends on a versioned linux-headers package, we will add a lot of maintenance overhead since we'll need to update the apparmor package every time the kernel has an ABI bump, otherwise it will FTBFS. The other option is a static file, which could conceivably go out of date as easily as the glibc version, or worse stay out of date longer than the glibc version. Am I missing something?