[elrepo-devel] Two things about kversion

[Alan Bartlett]

On 20 April 2010 02:29, Akemi Yagi <toracat at elrepo.org> wrote:

> (Q2) Is it a good idea to hardcode the kversion in the spec file?

As a result of private discuusions with Phil, yesterday, and thinking
about this overnight I can see no reason to object to the following:

(A1) All initial development work is performed with a %{!?kversion:
%define kversion %(uname -r)} line in the .spec file.
(A2) Once development is complete, that line is then changed to
provide the kernel "build-base" for which the package is built
against. In other words %{!?kversion: %define kversion
2.6.18-194.el5}, using dahdi-kmod-2.3.0-*.src.rpm, for an example.

> (Q1) Which version of kernel should a kmod package be built against?

(A3) Considering Levente's, Phil's and Dag's views -- all perfectly
valid -- I would say that it really depends upon circumstance and the
package being built. For some packages, I use the earliest kversion
that provides a correctly working package for the current point
release (at present, EL 5.5, the -194.el5 kernel series) and
weak-links to as many other point releases that is possible. Having
said that, I can see no real problem either building against the
-8.el5 or the -194.el5 series kernels if all point release weak-link
correctly. The only difference will be which version has the extra/
directory and which has the weak-updates/ directory. Take, for
example, the three Realtek NIC driver kmods that were the essential
"founding packages" of the ELRepo Project. Until quite recently, I was
routinely building them against the -8.el5 kernel. Then, due to
developments in the r8168.c code, I had to move to -128.el5 as the
build base. I regard this as an example of using the earliest possible
kernel version to allow the package to be used "full spectrum" (5.0 to
5.5 (and hopefully, beyond)). Therefore the is no direct rule that can
be applied -- it must be up to the packager's discretion.

Alan.