RHEL 6 and kABI/kmod Packaging

Jack Neely jjneely at ncsu.edu
Fri May 14 23:53:37 CEST 2010


Folks,

What can I do to help get rpmFusion branched for RHEL 6?  I have mirrors
of the beta setup here:

    http://ftp.linux.ncsu.edu/pub/redhat/linux/beta/6/

Being that folks seem more interested in trying the kABI method of
packaging kernel modules I've taken a look at what the current status of
that is and what work needs to go into that.

First off, there are no kernel modules in the RHEL 6 Beta.  However, all
the packaging foo that generate the ABI hash values are still in place.

I've looked at the gfs-kmod, kvm, and the ipw3945-kmod packages from
RHEL 5.  Unfortunately, Red Hat isn't so much as using a packaging
standard as we know and love them.  The source packages vary wildly from
the standard specs described in the kmodv1 standard.  The gfs-kmod and
ipw3945-kmod packages are, however, pretty close to kmodv1 standard.  I
don't really see anything that we couldn't deal with, but I would not
expect kmods packaged by Red Hat to be as consistent as we've been with
kmodv1 and v2.

As with kmodv1, the source packages include the kmodtool helper script.
I believe that the kmodtool provided by all three of the above packages
are different in minor ways.  Creating a standard version shouldn't be
hard.  The main difference with the script from kmodv1 is that the
script will insert in the kmod-foo package

    %global _use_internal_dependency_generator 0

Which makes RPM not use its internal dependency magic.  Rather, RPM uses
the following scripts to generate requires and provides:

    /usr/lib/rpm/redhat/find-requires
    /usr/lib/rpm/redhat/find-provides

The find-requires script will locate files in the package that look like
kernel modules (matches ^.*/lib/modules/(.*)/(.*).ko$) and if those
files are present find-requires executes

    /usr/lib/rpm/redhat/find-requires.ksyms

Which generate the kABI hash values that the kmod-foo package needs to
require.

I wanted to port my OpenAFS package to use kABI for the start of a
working proof of concept, but I was unable to build kABI packages in
mock.  The find-requires.ksyms script uses the 'join' command which
groks its file descriptors directly in /dev/fd/*.  That symlink is not
created in mock's /dev setup.  My attempts to bind mount my workstation's
/dev into the build chroot made other parts of the chroot creation
fail.[1]

Poking around with the kABI stuff leaves me with some questions for the
group:

This is very much kmodv1 with very few changes.  The nature of this
method keeps multiple installed packages and upgrading corner cases to a
minimum as only one kmod-foo package per kernel variant is needed.  No
kernel version-in-package-names.  Are there other features of kmodv2
that kABI doesn't in some way supply when applied to kmodv1?  Do we want
to update the kABI "standard" in any ways and will the resulting
differences in our standard vs. Red Hat's packages cause concern?

A Yum plugin may still be handy to cover some corner cases.  (Installing
a kmod-foo for all installed kernel variants.  Others?)

Red Hat tends to build their kABI kmods for kernels that were never
released.  These packages could have a tendency to clutter
/lib/modules/*

Would anyone know the right mock incantations to get these things to
build properly?

Once I have a working proof of concept building in mock I'll get the
rpmFusion wiki updated with some documentation of this standard.  

Jack Neely

[1]: Why this started failing I never figured out:

DEBUG util.py:291:  Executing command: ['perl', '-p', '-i', '-e', 's/^(mockbuild:)!!/$1/;', '/etc/passwd']
DEBUG util.py:330:  Child returncode was: 2


-- 
Jack Neely <jjneely at ncsu.edu>
Linux Czar, OIT Campus Linux Services
Office of Information Technology, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89


More information about the rpmfusion-developers mailing list