"Aaron M. Ucko" <u...@debian.org> writes: > Historically, /usr/src/linux-headers-VERSION-FLAVOR used to contain > symlinks into /usr/src/linux-headers-VERSION-common for anything not at > least potentially flavor-specific. As of 2.6.29-1, that no longer > holds, causing trouble for packages such as openafs-modules-source that > don't entirely defer to the kbuild framework. (OpenAFS is particularly > special due to its age and support for a wide range of platforms, and > makes symlinks to /lib/modules/VERSION-FLAVOR/build/include/linux in its > build tree so that it can variously include the headers as <h/*.h>, > <netinet/*.h>, and <sys/*.h>.) > > I have worked around the problem on my own system by throwing together a > package containing a portion of the dropped symlinks (those from and > into .../linux), but would appreciate it if you could please reinstate > the symlinks in the flavor-specific linux-headers packages.
We may also be able to fix the OpenAFS build system if this was an intentional architecture change to solve some problem, although as Aaron mentions OpenAFS has kernel build support for eight or nine different UNIXes and a compatibility layer which makes this trickier. What's the intended use of the new layout in these packages? Are modules expected to provide a search path for include files rather than assuming headers are in one unified location? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
