On Mon, Sep 26, 2005 at 05:16:24AM +1000, Paul TBBle Hampson wrote: > Package: linux-headers-2.6.12-1-686 > Severity: minor > Version: 2.6.12-6 > > A module collection that just uses: > @$(MAKE) -C $(KERNEL_SOURCES) SUBDIRS=$(shell pwd) modules_install > to install its kernel modules will try to put its output in > /lib/modules/2.6.12/extra > instead of > /lib/modules/2.6.12-1-686/extra > > This is because scritps/Makefile.modinst uses MODLIB, supplied from > Makefile as > $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE), > where KERNELRELEASE is the culprit, as it is built from > $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(LOCALVERSION) > and EXTRAVERSION is not set in the Makefile, as it is shared across all > of 2.6.12-1 > > There are two apparent mechanisms to deal with this. The package has a > .config, in which a CONFIG_LOCALVERSION could be set to get the correct > behaviour. > > Alternatively, a file called localversion-debian (actually > localversion*) could be created, which could contain the same string.
The latter of these options seems like it would be easiest to integrate into the kernel packages. > Either of these would cause modules to be able to install in the correct > place without any user intervention. (ie if they can find the headers, > they'll install in the right place) > > (I realise this is not the actual package at fault, but I'm not familiar > with the kernel-team's build or triage procedures, so I'll leave it to > you to put this against the right package.) -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
