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. %fedora_build even uses "awk".
In this case it decides to append ".1" to bump the final Release value
as a last resort.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
