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.
Most external components have been removed to simplify maintenance.
The following ones are kept because they are more important and/or
maintained well in upstream:
- BFQ
- AUFS
- ndiswrapper
- several bug fixes
reiser4 is kept too but disabled by default until its maintainers update
it for kernel 4.x.
Without it, the DKMS-modules built before might have been missed.
For the same reason, kernel-<...>-devel package is now in Requires(post)
for kernel-<...>. The former must be installed completely before we call
depmod for the latter.
Even if it already exists. This may happen if kernel-<...>-devel is
installed first, triggers rebuild of DKMS modules and some of these
request remaking of initrd. The initrd that is created then will be
non-functional. But when the user installs kernel-<...> package, that
defunct initrd will be replaced with a working one here.
Before this commit, DKMS was called to build and install the external
kernel modules when kernel-<flavour> packages were installed, and
only if the development files were also available.
This is error-prone because there is no guarantee the -devel package
creates the necessary files before. As a result, some proprietary
drivers could not be built when the kernel is updated.
This is an attempt to fix the problem. Because kernel-<flavour>-devel
package is enough to build kernel modules with DKMS, I moved these build
and install operations to kernel-<flavour>-devel from kernel-<flavour>.
Some of the related code was simplified as well.
We still use DKMS and provide DKMS-packages with widely used proprietary
drivers.
Although we do not recommend installing kernel-<flavour> package without
the corresponding devel package, some users still do so no matter what.
They get problems then due to the proprietary drivers failing to rebuild,
etc.
kernel-<flavour> now has kernel-<flavour>-devel in "Suggests:" to
mitigate this.
On EeePC 1015 PED (in Live mode), cpupower.service seemed to start too
early, before /sys/devices/.../scaling_available_governors was there,
and failed as a result. There were no such problems on faster machines,
but still.
Now cpupower.service will start only when 'scaling_available_governors'
file is available. cpupower.path unit handles this. If CPU frequency
scaling is not supported the file will never appear and cpupower.service
will not start at all, which is natural.
Should fix bug #4810.
cpupower will now select the governor automatically during the start of
the service, based on what is available. This can be overridden with
the variables in /etc/sysconfig/cpupower (see the comments there).
