We are different: kernel changelog

Jarod Wilson jarod at redhat.com
Tue Feb 10 15:30:48 UTC 2009


Michael Schwendt wrote:
> On Mon, 9 Feb 2009 13:33:58 -0500, Dave wrote:
> 
>> On Mon, Feb 09, 2009 at 01:27:10PM -0500, Christopher Aillon wrote:
>>  > On 02/09/2009 01:12 PM, Dave Jones wrote:
>>  > > On Mon, Feb 09, 2009 at 09:50:15AM -0500, Jarod Wilson wrote:
>>  > >  
>>  > >  > For rawhide, its a bit messy and most folks don't want to waste time 
>>  > >  > from working on code to figure out how to determine the EVR of the hour 
>>  > >  > (granted, yes, 'make verrel' and add one to the appropriate place is all 
>>  > >  > it is...). A fair number of rawhide updates are done in a scripted 
>>  > >  > fashion, guess we could add logic to the script to include an EVR.
>>  > > 
>>  > > If bumpspecfile.py had smarts to insert the version number, it'd be great.
>>  > > As all the rebases, and some of the other changes are scripted already anyway.
>>  > 
>>  > It does.  Though not sure how it will handle the foo that happens with 
>>  > kernel versioning.
>>
>> It does the right thing by trying to evaluate it, and putting what it thinks
>> the result is in the right place, but unfortunatly, it also bumps Release:
>> (Even if Release: isn't a number, but a macro)
>> which screws things up horribly, resulting in versions like 2.6.29-0.100.rc4.git1.1
>>
> 
> It does not evaluate it to bump it, though. It only does that when adding
> the changelog entries -- and that would work fine if the script got an
> option to "not bump". ;)
> 
> To bump release values, it tries to recognise several types of common
> "Release" value definitions directly in hope that they adhere to the
> guidelines.
> 
> With so many macros
> 
> | %define pkg_release %{fedora_build}%{?stable_rctag}%{?buildid}%{?dist}
> | Release: %{pkg_release}
> 
> it would simply need to be *much* more mighty, before it could find the
> right value to bump.

Thing is... There *is* no right value to bump. Bumps happen 
automagically based on cvs version. So what we need is something that 
evaluates the current version and adds one to the %fedora_build field to 
"get it right" for the next cvs commit.

-- 
Jarod Wilson
jarod at redhat.com







More information about the fedora-devel-list mailing list