There are some manual hacks in the kernel specfile now for building
stable release candidates. However, kernel 2.6.23.9-rc1 ends up being
released as 2.6.23.8-NN because we don''t have a good way to change the
version. This update automates that; the only question is whether we
should label the built kernel as an -rc. I didn''t add that part, and
the
changes are untested:
--- kernel.spec 29 Nov 2007 00:25:06 -0000 1.279
+++ kernel.spec 29 Nov 2007 22:45:41 -0000
@@ -34,6 +34,15 @@
%if 0%{?released_kernel}
# Do we have a 2.6.21.y update to apply?
%define stable_update 9
+# Do we have a stable RC update to apply?
+%define stable_rc 0
+# Stable rc patches are incremental against the previous -stable
+# If this is an rc we need the previous stable patch too
+%if 0%{?stable_rc}
+%define stable_base %(expr %{stable_update} - 1)
+%else
+%define stable_base %{stable_update}
+%endif
# Set rpm version accordingly
%if 0%{?stable_update}
%define stablerev .%{stable_update}
@@ -534,8 +543,12 @@
# Here should be only the patches up to the upstream canonical Linus tree.
# For a stable release kernel
-%if 0%{?stable_update}
-Patch00: patch-2.6.%{base_sublevel}.%{stable_update}.bz2
+%if 0%{?stable_base}
+Patch00: patch-2.6.%{base_sublevel}.%{stable_base}.bz2
+%endif
+%if 0%{?stable_rc}
+Patch01: patch-2.6.%{base_sublevel}.%{stable_update}-rc%{stable_rc}.bz2
+%endif
# non-released_kernel case
# These are automagically defined by the rcrev and gitrev values set up
@@ -1006,8 +1019,12 @@
# Update to latest upstream.
# released_kernel with stable_update available case
-%if 0%{?stable_update}
-ApplyPatch patch-2.6.%{base_sublevel}.%{stable_update}.bz2
+%if 0%{?stable_base}
+ApplyPatch patch-2.6.%{base_sublevel}.%{stable_base}.bz2
+%endif
+%if 0%{?stable_rc}
+ApplyPatch patch-2.6.%{base_sublevel}.%{stable_update}-rc%{stable_rc}.bz2
+%endif
# non-released_kernel case
%else