[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#521515: linux-headers-2.6.29-1-amd64: please restore symlinks into -common



"Aaron M. Ucko" <ucko@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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: