Dave Jones wrote: > On Tue, Jul 03, 2007 at 11:47:18AM -0500, Tom spot Callaway wrote: > > > This is why Fedora adopted the pre-release versioning scheme that we > > did: > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages > > > > In the Fedora scheme, this would be > > > > 0.%{X}.%{alphatag} > > > > Or, in your specific example: > > > > kernel-2.6.22-0.2.rc7.git1.fc8 vs kernel-2.6.22-0.1.rc7.fc8 > > Ok, that looks fixable by doing this.. Damn, I looked at that particular case and everything was just fine with it in my head... Stupid head. > Jarod, want to give this a quick once-over? Yup. > Index: kernel-2.6.spec > =================================================================== > RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v > retrieving revision 1.3257 > diff -u -p -r1.3257 kernel-2.6.spec > --- kernel-2.6.spec 3 Jul 2007 16:45:36 -0000 1.3257 > +++ kernel-2.6.spec 3 Jul 2007 18:45:22 -0000 > @@ -15,7 +15,7 @@ Summary: The Linux kernel (the core of t > > # fedora_build defines which build revision of this kernel version we're building. In the > # non-kernel world, this is analogous to the Release: field, and is formatted similarly. > -%define fedora_build 2%{?dist} > +%define fedora_build 2 I might change the comment here slightly, since w/o %{?dist} right there, its not quite the same as Release: anymore, but that's neither here nor there for actually fixing the problem... :) > # base_sublevel is the kernel version we're starting with and patching > # on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base, > @@ -107,7 +107,7 @@ Summary: The Linux kernel (the core of t > > # pkg_release is what we'll fill in for the rpm Release: field > %if %{released_kernel} > -%define pkg_release %{fedora_build}%{?buildid} > +%define pkg_release %{fedora_build}%{?dist}%{?buildid} > %else > %if 0%{?rcrev} > %define rctag .rc%rcrev > @@ -118,7 +118,7 @@ Summary: The Linux kernel (the core of t > %define rctag .rc0 > %endif > %endif > -%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid} > +%define pkg_release 0.%{fedora_build}%{?buildid}%{?rctag}%{?gittag}%{?dist} > %endif > > # The kernel tarball/base version > > > Note that for this to work, you need to increment %{X} upon every new > > package. > > It's non-obvious to me what %{?buildid} is, but it seems to > auto-increment. The %buildid is for one-off builds, there's a blurb at the top of the spec where we request people to set it for their own custom builds for identifying non-official kernels. Never set in official fedora builds. The order of it in pkg_release probably doesn't matter too much, though I personally like it at the very end. Otherwise, the changes look fine to me. The other crazy idea I had was to call 2.6.22-rc7 2.6.22-0.rc7.git0.1.fc8. Making fedora_build auto-increment is probably cleaner, though it'd be nice to also have it reset on a kernel major version rebase (either manually or automagically). -- Jarod Wilson jwilson@xxxxxxxxxx
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
