Re: kbuild: Fix the breakage caused by "improve version string logic"

[Boaz Harrosh]

On 06/09/2010 09:55 AM, David Rientjes wrote:
> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
> 
>> What is a tagged commit:
>>
>> [my_tree] $ git branch
>> *master
>> [my_tree] $ git tag v2.6.35-rc2-my-tree
>> [my_tree] $ cat localversion-my-tree
>> -my-tree
>>
>> I still get: DEPMOD 2.6.35-rc2-my-tree+
>>
>> How to solve? please specify.
>>
> 
> You need to use git tag -a.
> 

Right, I got that

>> In my tree there is 2.6.35-rc2-my-tree so it cannot be mistaken with
>> Linus tree.
>>
> 
> Just because you have appended "-my-tree" to the version string does not 
> mean it is not vanilla 2.6.35-rc2.  You could append information such as 
> that just for a different config, for instance.  

No, this is all naming convention. Just like the '+' is. If it was a config
thing then it would be added via CONFIG_LOCALVERSION and *appended* to any
compilation using that config. From a git tree you get added the localversion*
file that gets pulled by a checkout. and so on. So at a glance I know that
the presence of my_tree was added because it is from my tree. They are all
chained and ordered so we know exactly what contributed what.

> The `+' modifies the base 
> kernel version (2.6.35-rc2), not the string itself or whatever you choose 
> to add to it.
> 

Not, correct. As you yourself explained. The `+' modifies any Kernel that
is not a "tag -a" and/or modified from the tree it derives from.
Base kernel version has nothing to do with it.

>>> As mentioned previously, you can easily suppress that from being added by 
>>> using "make LOCALVERSION=-foo" to create a 2.6.35-rc2-foo kernel when you 
>>> do not have CONFIG_LOCALVERSION_AUTO enabled.  You already found that you 
>>> cannot pass an empty LOCALVERSION string, so it must be something to 
>>> identify itself as unique from vanilla 2.6.35-rc2.
>>>
>>
>> As mentioned previously this is not an option I do not have git control
>> over how this gets compiled.
>>
> 
> If your git repository is publically accessible, it is very simple to tag 
> commits that you want your users to pull from to indicate it's a 
> "release".  That allows you to determine whether other users have extra 
> commits on top of your release when they send you bug reports, for 
> example, which is quite helpful.

Sigh, I give up. Let me spell it out for you once more and I'll not mention
this again:
  "For multitude of reasons, there are times that even when running from
   a git tree, I wish to compile a Kernel as if it's from a tar-ball. .i.e
   Don't poke in my git tree for this compilation."

Because I'm cross compiling, because I'm bisecting, because my scripts and
environment demand specific names, because i need to save space and time...

But it seems I will not be granted my wish. I'll go damage my
scripts/setlocalversion and be done with this.

Thanks
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/