Until now, the build system for the kernel supported a number of
flavours: nrj and non-nrj ones, desktop-, laptop-, server- and
netbook-oriented, etc.
It turned out over the years, however, that our users mostly need the
following:
* a kernel to use on the desktops (home and office use) with reasonable
default settings for performance and responsiveness;
* a kernel for laptops, with a bit more emphasis on power consumption.
Other variants were rarely used. We also did not have enough time to
properly support all these.
Besides, the kernels for ARM and other architectures need a somewhat
different build process than for x86. So, they are better off to be in
separate ABF projects, even if they are needed. No signs of ROSA on ARM
yet, btw.
So, I kept only nrj-desktop and nrj-laptop flavours and only x86.
Non-PAE systems also seem to be rare now, so I enabled PAE by default
for the 32-bit kernels. Non-PAE kernels are no longer built. If they are
needed, we may use a separate git branch or an ABF project for that.
To simplify debugging, maintenance and experimentation with the kernel
builds further, I revisited the process of preparing the kernel
configuration files. The goal is to get rid of a separate git repo with
the default configs (kernel-patches-and-configs) and keep everything in
this project.
The default config files are now kept here. For x86_64:
* kernel-x86_64.config contains the options for both nrj-desktop and
nrn-laptop flavours;
* kernel-{nrj_desktop|nrj_laptop}-x86_64.config files contain the
flavour-specific options.
This way, it is easier to track which config options changed when,
easier to experiment with the custom configs and so on.
The kernel will be built with debug info if rpmbuild is called with
"--with debug".
Only kernel*-<major>.<minor>-latest should be built. Same for the
development packages.
We now encourage the users to install kernel*-<major>.<minor>-latest
explicitly if they want a different branch of the kernel. Less confusion
as a result.
It seems, rpm does not like it when the name of the package ends with,
say, "-3.14". For example, it does not process the update from
kernel-nrj-desktop-3.14-3.14.57-2 to
kernel-nrj-desktop-3.14-3.14.57-3 correctly: the former package is not
removed as both are installed as a result.
kernel-nrj-desktop-3.14-latest-3.14.57-2 and
kernel-nrj-desktop-3.14-latest-3.14.57-3 seem to be processed OK, so let
us use this variant.
kernel-{flavour}-{major}.{minor} will require the latest kernel package
for kernel {major}.{minor}.x series.
kernel-{flavour}-{major}.{minor}-devel will do the same for -devel
packages.
This should allow the users to keep, say, kernel 4.1.x and get updates
for it even if 4.2.x is in the repositories.
If it is desired to have the latest of the available kernels,
kernel-{flavour}-latest should be used, the same way as before.
The kernel was updated to version 4.2.3.
3rd party additions (ndiswrapper) have been dropped.
The fixes for e1000e and mt7601u have been added as well, see
"kernel-patches-and-configs" project, branch v4.2.x.
The tag had to contain both the version and the release of the package.
This is inconvenient when mass rebuilds are in action: the release is
incremented automatically then.
Using the top of the appropriate branch is safer. It is also possible to
specify any other revision, so this scheme is more flexible as well.
It is no longer required to upload each archive
kernel-patches-and-configs.* to FileStore. They are now retrieved from
https://abf.io/soft/kernel-patches-and-configs/ according to the git
tags.
If you are going to build kernel version X.Y.Z release R, you need to
tag the appropriate commit in kernel-patches-and-configs git repo as
"X.Y.Z-R", without quotes.
For experiments and testing, one may still upload the archives with the
pacthes and configs to FileStore and probably edit the URL in SOURCE100
in the spec.
