[elrepo-devel] Two things about kversion

[Dag Wieers]

On Mon, 19 Apr 2010, Akemi Yagi wrote:

> I would like to start a discussion about a couple of things regarding
> "kversion".
>
> (1) Which version of kernel should a kmod package be built against?
>
> Many kmod packages provided by ELRepo are compatible through all
> versions of kernel within CentOS 5.x thanks to the kABI. However,
> there are those that are valid only with certain version and up.  So,
> the question arises: should we always build a kmod package against the
> oldest possible kernel -- or the newest possible --or -- ?

I have a clear preference for using the oldest possible kernel as a basis 
for the kmod packages we produce. There are a few good reasons for this:

  - It becomes possible to query a package to find the oldest supported
    kernel, this is something we later could use for automated
    documentation.

  - It gives an inambiguous indication, while using the latest would either
    mean we have to build against every new kernel, or it might be
    interpreted as not supporting later kernels.

Ofcourse, if we think the above is important it does mean that we have to 
determine the oldest supported kernel manually. Which may mean a 2-phased 
process to determine the oldest 'major' kernel that works.


> (2) Is it a good idea to hardcode the kversion in the spec file?
>
> This question is related to the first one. It is not instantly obvious
> which kernel was used as a base for a given kmod.  Hardoding the
> kversion in the spec file would make it easy to identify it.  Another
> reason (and this may be more important) is that mock can be used for
> building if kversion is defined in the spec.
>
> Please let me know your thoughts.

Since we can override the kversion on the commandline, there is no need to 
hardcode it. However hardcoding it (or standardizing comments in the SPEC 
file) could help in explicit documentation as part of the process of 
determining the oldest kernel that is supported.

I always tried to use the SPEC file as a way to keep documentation close 
to the 'code' and therefor putting this information somewhere in the SPEC 
file might be a good idea to centralize metadata. (Or in the future even 
instruct the buildsystem)

When RHEL6 is released it may become possible to provide a specific driver 
to both RHEL5 and RHEL6 kernels, we may want to do this from a single SPEC 
file (like we do with RPMforge where possible) or from forked SPEC files 
(which is the default in EPEL).

In essence it is up to the people that do the work, and have to use the 
workflow/processes that we define. What works best for them is what we 
should adopt.

-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]