Hi Afzal, sorry for the late feedback. On 13.9.2013 23:49, Afzal Mohammed wrote: > If a private tag is created after the most recent kernelversion tag, a > commit after this private tag would feed kernelrelease with commits > after private tag and kernelversion tag. This may confuse user relying > on kernelrelease (mostly a developer while debugging), mainly if HEAD > has a private tag and otherwise w.r.t git distance from kernelversion > tag. The solution is simple: Do not use private annotated tags. Or rather, if you are creating an annotated tag, modify EXTRAVERSION accordingly. Any automagic based on the tag name is going to fail in some way. > Instead if such a tag is created at say HEAD~, kernelrelease would be > v3.11.0-rc1-00001-gdeadbeef, misleading the observer w.r.t git distance > from nearest kernelversion tag. > > Here an attempt is made to prevent private tag from altering > kernelrelease. > > Signed-off-by: Afzal Mohammed <afzal.mohd.ma@xxxxxxxxx> > --- > > Hi, > > This seems to work on different scenarios that could be readily thought > of. I am shaky about this change, but acheives the purpose. With your change, the script considers e.g. the next-YYYYMMDD tags "private." > define filechk_kernel.release > - echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree))" > + echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree) $(KERNELVERSION))" > $@ > endef The >$@ should not be there. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
