problem: LOCALVERSION is being used to identify different repositories from git, and is usually overloaded when using a locally modified kernel repository. `modules-update rebuild` will instruct all packages which are dependant of the linux kernel to remerge using the linux-info.eclass to identify which kernel they have to build against with, and where to get the modules installed, but the kernel version detected doesn't include LOCALVERSION and therefore the modules get installed on the wrong directory. way to replicate : cg clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git #configure, compile and install kernel reboot modules-update rebuild the kernel version detected will be 2.6.15, which corresponds with a vanilla 2.6.15 kernel, even if `uname -r` shows 2.6.15-g???? and the modules are installed in /lib/modules/`uname -r`
Created attachment 76501 [details, diff] patch which defines KV_LOCAL correctly so that KV_FULL matches this patch mostly ignores several further tests and logic for KV_LOCAL which is not working correctly anyway, and as it is made to default to the right values with the setting at this time, and as tested
Thanks for investigating. Your patch will break in the case of a seperate output directory (KV_LOCAL unconditionally overwritten on line 289), and we should fix the localversion detection rather than just declaring it as broken. I think the current implementation is working in that it reads CONFIG_LOCALVERSION from the users .config and reads the /usr/src/linux/localversion* files. What it doesn't do is read LOCALVERSION from the top-level Makefile, and if this is an accepted way of modifying the version string (if so, it is something new) then you need to figure out at which position in the localversion it gets inserted, and modify the eclass accordingly.
the use of an automatic local identifier is triggered by the use of CONFIG_LOCALVERSION_AUTO (set by default) as shown by the following comment from the Makefile : # If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called # and if the SCM is know a tag from the SCM is appended. # The appended tag is determinded by the SCM used. # # Currently, only git is supported. # Other SCMs can edit scripts/setlocalversion and add the appropriate # checks as needed. from the comments I found on the old (pre 2.6.16) kernels it seems to be a feature added around 2.6.9 and explains as the primary goal the posibility to autodetect if a tree is used for development and avoid overwriting the production tree with the same number at install time. my comments about the test being broken (which i meant was going to be broken after my patch was applied as they are not both consistent), were related to my understanding of the heuristics being used to detect the LOCALVERSION which try to mimic what the Makefile does, instead of just "executing" the Makefile and getting the expected result from it (which can be done by using the getfilevar call as suggested on the original patch), as well as the logic and comments starting on line 276 and which rationale/comments are not clear, at least to me. note also that the current code has a dependency issue as detailed on bug 118630 , as the tests for LOCALVERSION currently rely on the existency of .config, eventhough the test for its existence is done later, aborting the process with the wrong error, and which therefore would need to be swapped as well for a final solution, and could be part of the rationale of why the checks for LOCALVERSION are currenlty being done this way.
This is somethign I need to look into to confirm. Until extremely recently we haven't supported git sources and was never a requirement.
*** Bug 196675 has been marked as a duplicate of this bug. ***
Please sync and retest, the code has changed a lot since this bug was opened.
