From Fedora Project Wiki

< Kernel

Revision as of 16:55, 14 April 2015 by Jwboyer (talk | contribs) (Created page with "= The Fedora kernel.spec = Like all RPMs, the Fedora kernel starts with a spec file and a set of tarballs and patches. This page will describe some of the sections of the ke...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The Fedora kernel.spec

Like all RPMs, the Fedora kernel starts with a spec file and a set of tarballs and patches. This page will describe some of the sections of the kernel.spec file, what they're used for, and how to modify them.

Macros

There are a few important macros that we modify often. These are listed below.

%global released_kernel

The released_kernel macro controls whether the rest of the macros and functions are dealing with an upstream released final kernel version. In the stable Fedora branches, this should almost always be set to 1. This will tell the other macros to use the final tarball (e.g. linux-4.0.tar.xz) and base_sublevel as the basis for the version numbers. In rawhide, released_kernel will often be set to 0 as we often ship pre-release git snapshots and -rcX kernels. Having it set to 0 will cause the proper versioning to happen for these non-released kernels.

%define base_sublevel

The base_sublevel macro sets up the portion of the versioning after the major version number. E.g. base_sublevel of 0 will be 4.0. If it is set to 1, the versioning will be 1. Note, it is a reflection of the actual tarball we are building on top of, so if released_kernel is 0, base_sublevel will still be using the previous version. E.g. 4.1-rc1.git1 starts with the 4.0 tarball, so base_sublevel should be 0.

%define stable_update

The stable_update macro controls the .y portion of the versioning and is responsible for applying the upstream stable release patches. If it is set to 0, no stable patch will be applied. If it is set to another number, it will apply that .y version number on top of the base_sublevel tarball. E.g. stable_update 2 and base_sublevel 0 would apply patch-4.0.2.xz on top of linux-4.0.tar.xz. This macro is only in use when released_kernel is 1.

%define rcrev

When released_kernel is 0, we are building RC or merge window kernels. The rcrev macro contains the numeric value of the upstream RC release for the kernel we are targetting. Merge window kernels will have an rcrev of 0. All other -rcX releases will match their upstream release, e.g. 4.1-rc2 would have an rcrev value of 2. This macro is not used when released_kernel is 1.

%define gitrev

When we build a git snapshot kernel, the gitrev macro contains the value of the git snapshot patch to apply. E.g. 4.1-rc2-git3 would have a gitrev value of 3. This will cause the spec to apply patch-4.1-rc2-git3.xz on top of linux-4.0.xz+patch-4.1-rc2.xz. This is not used when released_kernel is 0.

Note: We have a script that generated the git snapshot patches and will modify this value in the spec accordingly. Manual modification of this macro does not happen often.