From Fedora Project Wiki
(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...")
 
(Add initial sources section)
Line 28: Line 28:


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.
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.
<code>%global baserelease</code>
The baserelease macro controls the final number in the RPM Release field.  E.g a 4.0.0-1.fc23 kernel has a baserelease value of 1.  4.1.0-0.rc2.git1.3.fc23 has a baserelease value of 3.  This macro is the most often edited macro we have and should be modified for every commit we do.  When we rebase to a new kernel, we reset it back to the value appropriate for that branch.  To help with upgrade paths, each Fedora branch has a different starting value for baserelease.  These are listed below.
* rawhide/Branched: Starts at 1 and increments from there.
* Most recent stable release N: Starts at 300 and increments from there
* N-1 release: Starts at 200 and increments from there
* N-2 release: Starts at 100 and increments from there
This way, the oldest release always has the "oldest" Name-Version-Release combination for that upstream kernel release.
There are other macros that control some other things, however we'll skip those for now and focus on the main macros used for build output.
=== Sources ===
===== Tarballs and large patch files =====
The sources file lists the tarballs and large patch files that we used to explode the kernel sources.  It will contain the file name and a hash value for that file.  The contents will look similar to:
<pre>
a86916bd12798220da9eb4a1eec3616d  linux-4.0.tar.xz
d125eecce68ab6fb5f1f23523c2c04b8  perf-man-4.0.tar.gz
</pre>
The perf-man tarball is a self created tarball of the perf man pages.  This is generated once per upstream kernel release.  As -rcX patches are released and git snapshots are generated, we also add those via the sources file.  This is done with the <code>fedpkg upload 'filename'</code> command.
===== Individual patches =====

Revision as of 17:09, 14 April 2015

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.

%global baserelease

The baserelease macro controls the final number in the RPM Release field. E.g a 4.0.0-1.fc23 kernel has a baserelease value of 1. 4.1.0-0.rc2.git1.3.fc23 has a baserelease value of 3. This macro is the most often edited macro we have and should be modified for every commit we do. When we rebase to a new kernel, we reset it back to the value appropriate for that branch. To help with upgrade paths, each Fedora branch has a different starting value for baserelease. These are listed below.

* rawhide/Branched: Starts at 1 and increments from there.
* Most recent stable release N: Starts at 300 and increments from there
* N-1 release: Starts at 200 and increments from there
* N-2 release: Starts at 100 and increments from there

This way, the oldest release always has the "oldest" Name-Version-Release combination for that upstream kernel release.

There are other macros that control some other things, however we'll skip those for now and focus on the main macros used for build output.

Sources

Tarballs and large patch files

The sources file lists the tarballs and large patch files that we used to explode the kernel sources. It will contain the file name and a hash value for that file. The contents will look similar to:

a86916bd12798220da9eb4a1eec3616d  linux-4.0.tar.xz
d125eecce68ab6fb5f1f23523c2c04b8  perf-man-4.0.tar.gz

The perf-man tarball is a self created tarball of the perf man pages. This is generated once per upstream kernel release. As -rcX patches are released and git snapshots are generated, we also add those via the sources file. This is done with the fedpkg upload 'filename' command.

Individual patches