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

Tom 'spot' Callaway tcallawa at redhat.com
Wed Jun 29 13:38:45 UTC 2005

On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote:
> On Tue, Jun 28, 2005 at 07:40:52PM -0500, Tom 'spot' Callaway wrote:
> > - 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.
> Leaving everything else aside for a sec, this doesn't screw up bugzilla if
> you do it as a subpackage -- same way kernel and kernel-smp don't.

I think we have to assume that there will be some kernel-module packages
that just consist of drivers, with no extra user space addons.

> I think it's better to have this in the release:
> > Release: %{kver}
> > (Where %{kver} is the kernel we're building against)
> > Requires: kernel-%{_target_cpu} = %{kver}
> > BuildRequires: kernel-devel-%{_target_cpu} = %{kver}
> Release: %{realpackagerelease}.%{kver}

OK, so lets say we do this.

In this case, we have %{kver} in %{release} to keep %{release} unique
(and thus, have unique NVR). However, we can no longer just use
%{release} as our check variable in yum. In this scenario, we need to
instead make yum check some sort of "magic" provides that only
kernel-module packages will have (not as much of a hack as might be

In the spec, we put:

Provides: kernel-module-openafs-kver = %{kver}

Basically, to modify my original yum logic path:

- Does any kernel-module-openafs package exist on the system with the
same kernel-module-openafs-kver?
- If yes, remove it (rpm -e). If no, continue.
- Install new package (rpm -i).

> Oh, there's another problem -- can't have a "-" in the release #.

%define cleankver %(echo %{kver} | sed s,-,_,g)

> My only concern here is maybe particular to openafs -- the kernel module
> source isn't distributed separately from the other library/userspace/gunk. I
> guess I *could* make an openafs.src.rpm and a separate
> openafs-kernel.src.rpm both containing the same source tarball, but that
> seems kinda wrong. On the other hand, hey, maybe it isn't.

Or you could make the userspace gunk in a subpackage. No reason that
kernel-module-openafs can't generate both kernel-module-openafs and
openafs packages.

You can override the version and release for the openafs package.

> Haven't thought this through completely, but there's one more factor too:
> kernel-module-openafs-1.3.84 will be required by the openafs-client package.

Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps
the remove, knowing that the install is coming right afterward.

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!

More information about the Fedora-packaging mailing list