[Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad)

[Jack Neely]

> Actually, no. I'm not going to standardize kernel module packaging
> _UNTIL_ at least yum is fixed.
> 
> Let me reiterate some points that I have made in the past:

Good, gets us all back on track.  :-)

> 
> - I do not plan to overload the %{name} value for kernel module
> packages. This means that we will NOT be shoving the kernel version in
> %{name}. Its ugly, it screws up bugzilla, breaks existing packaging
> guidelines, and is altogether wrong.
> 
> - Given that, we WILL need to put the kernel version (in some part) in
> either %{version} or %{release}. Let me explain why:
> 

I can tolerate %{release}

> On SMP systems, at a bare minimum, there will be two kernels installed:
> 
> kernel-smp-2.6.12-1.1400_FC5
> kernel-2.6.12-1.1400_FC5
> 
> If we do not use kernel version in either %{version} or %{release},
> we'll have no way to generate two packages with unique
> %{name}-%{version}-%{release} values.
> 
> We have to assume that each installed kernel will want to have a
> matching module addon installed for it.
> 
> I originally proposed (back in March) that we put the kernel version in
> Release. This is a slightly revised proposal.
> 
> Name: kernel-module-openafs
> (where the value in the Name field is the name of the module, prepended
> with "kernel-module-")
> Version: 1.1
> (where the value in the Version field is equivalent to the kernel module
> version, NOT the kernel version we're building against (in this example,
> "1", followed by the build revision, in this example ".1")

So %{version} ends up having the upstream version number and the release
number combined.  I think this is the worst part as its confusing to the
packager.  Why I advocate requiring %{kver}.  However, I did not propose
a solution for a unique NVR for eatch kernel type (smp, xen, etc).

> Release: %{kver}
> (Where %{kver} is the kernel we're building against)
> Requires: kernel-%{_target_cpu} = %{kver}
> BuildRequires: kernel-devel-%{_target_cpu} = %{kver}
> 
> %{kver} gets passed by the buildsystem, for each kernel found in the
> branch for which that package is being built. So, for our example
> kernels, %{kver} would be 2.6.12-1.1400_FC5 and 2.6.12-1.1400_FC5smp,
> respectively. FC4 and newer kernels have this value in the provides for
> "kernel-%{arch}", so it should not be too difficult for the build system
> to figure out the correct value for %{kver} from the target kernel
> package.
> 
> There is no need to use dist tags here, since %{kver} includes the dist
> name.
> 
> If a bugfix needs to be made to the package, then the .1 (build
> revision) is incremented. If a new version of the kernel driver is
> released, then the first part of the Version is incremented, and the
> build revision is reset to .1 (if it is not .1).
> 
> So, after the buildsystem does its thing, we've generated two new binary
> rpms:
> 
> kernel-module-openafs-1.1-2.6.12-1.1400_FC5.i686.rpm
> kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp.i686.rpm
> 
> Since no previous packages with those n-v-r's exist, yum installs them,
> just as it would kernels, doing the equivalent of an rpm -i action.
> 
> Now, on the system we have all four packages installed:
> 
> kernel-2.6.12-1.1400_FC5
> kernel-module-openafs-1.1-2.6.12-1.1400_FC5
> kernel-smp-2.6.12-1.1400_FC5
> kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp
> 
> But wait, I've found a bug in kernel-module-openafs. Easy enough to fix,
> I patch it away, increment my build revision to .2, and we now have
> these new packages available:
> 
> kernel-module-openafs-1.2-2.6.12-1.1400_FC5.i686.rpm
> kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp.i686.rpm
> 
> But, here yum doesn't know what to do. We can't do a -i, those packages
> would conflict with the existing kernel-module-openafs packages. We
> can't do a -U, because then we'd only end up with one
> kernel-module-openafs package on the system. What we need yum to do is a
> special operation that does the following (only for kernel-module
> packages):
> 
> - Does any kernel-module-openafs package exist on the system with the
> same %{release}?
> - If yes, remove it (rpm -e). If no, continue.
> - Install new package (rpm -i).
> 

I have a patch for yum that does exactly this except it keys off of the
kernel requires.  (Does kernel-module-openafs-1.1-2.6.12-1.1400_FC5
require the same kernel as kernel-module-openafs-1.2-2.6.12-1.1400_FC5?)
So in a day or two I could probably have it edited to do the above.

> After this process, the system has:
> 
> kernel-2.6.12-1.1400_FC5
> kernel-module-openafs-1.2-2.6.12-1.1400_FC5
> kernel-smp-2.6.12-1.1400_FC5
> kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp
> 
> Now, if someone is willing and able to write the exception case needed
> for yum in kernel-module-* packages, then I think we can document the
> remaining standard bits, duct tape the necessary logic into the
> buildsystem, and start doing kernel-module-* packages for FC4 and devel.
> 

Since I already have a good bit of the code done...

Spot, the only change I would like in this is to have the build number
not in %{version} but as part of %{release}.  So using your example,

    kernel-module-openafs-1-2.2.6.12-1.1400_FC5

Where the %{release} == build#.%{kver}

This doesn't add or subtract any complexity from the code in Yum.  It
does make the versioning a little easier to grok.

Reading the new mail I got as I wrote this it looks like Matthew and I
agree.  Cool.

Jack

> ~spot
> -- 
> Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
> Fedora Extras Steering Committee Member (RPM Standards and Practices)
> Aurora Linux Project Leader: http://auroralinux.org
> Lemurs, llamas, and sparcs, oh my!
> 
> --
> Fedora-packaging mailing list
> Fedora-packaging at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging

-- 
Jack Neely <slack at quackmaster.net>
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89