Auto rebuild release bump issue
Michael Schwendt
mschwendt at gmail.com
Sun Mar 9 02:51:58 UTC 2008
On Sat, 23 Feb 2008 11:38:17 +0000 (UTC), Kevin Kofler wrote:
> > Also added in cvs is a fallback, where a release string that doesn't
> > match at all is tried to be bumped at the very right, and if that
> > is not possible, ".1" is appended.
>
> Are you sure you want to autobump Release entries which don't match any of the
> templates in the guidelines?
Some numbers from a couple of background test-runs with rawhide cvs:
5472 spec files use an ordinary "Release:" tag close to the guidelines
10 spec files do "%define release ..." or "%define RELEASE ..."
6 spec files do "%define rel ..."
19 spec files do "Release: %release_func ..."
1 spec file does "%define baserelease ..."
~38 spec files are macro-overloaded beyond recognition, a few of them
even pull %version and %release from %SOURCE1 using awk
Of the 5472, some get the pre-release versioning scheme wrong or use lots
of macros to make it less readable (also for any security response team
people who may need to touch something like that), e.g.
ghdl.spec : 0.%{ghdlsvnver}svn.7%{?dist}
ochusha.spec : 0.%{vendor_rel}.%{strtag}%{?dist}
gnome-mount.spec : 0.svn20080225.4%{?dist}
libapreq2.spec : 0.rc2.14%{?dist}
*eewh*:
%define rel %{?minorver:0.}%{fedorarel}%{?minorver:.%minorver}
*ouch*:
gdm.spec
-0.2008.02.29.3%{?dist}
+0.2009.02.29.3%{?dist}
Stuff appended right of the dist-tag could be recognised and deleted
to be less ugly,
cups-pdf.spec
-6%{?dist}.2
+7%{?dist}.2
but then the bumper would still not round to integer values in
corner-cases like
crash.spec
-6.0.5
+7.0.5
because the context of the least-significant numbers is unknown.
More information about the fedora-devel-list
mailing list