[Fedora-packaging] kernel-module rpm's - final decision?

[Tom 'spot' Callaway]

On Wed, 2005-03-02 at 10:51 -0600, Troy Dawson wrote:
>Hello,
>As we are currently working on our openafs package, I want to make sure 
>our kernel modules for it conform to what was agreed upon.  But other 
>than the naming, I didn't see a definate 'this is how to do them' list. 
>  (If I missed that, point me to it)
>
>Here's what I saw.  My example will be openafs, but I am meaning this 
>for others as well.
>
>Name: kernel-module-openafs
>Version: 1.3.9
>Release: 2.6.9-5.0.3.EL.4
>Requires: kernel = 2.6.9-5.0.3.EL
>Provides: kernel-module-openafs

To be fair, we haven't finished the kernel-module-* naming and packaging
guidelines. I've been busy. :/

I really think in order for kernel-module packages to be manageable
(without disgusting yum and apt hacks), rpm needs to be able to do an
"UpdateOnlyOne" operation. Right now, it can't do that, it can only
"UpdateOneAndRemoveAllMatches".

However, in the interim, I think the following guidelines should be good
practice:

Name: kernel-module-openafs
(where the value in the Name field is the name of the module, prepended
with "kernel-module-")
Version: 1
(where the value in the Version field is equivalent to the kernel module
version, NOT the kernel version we're building against)
Release: %{kver}.1
(Where %{kver} is the kernel we're building against, and the .1 is a
build revision, incremented if we need to make changes to the same
version and kernel build)
Requires: %{kver}

(Do we need the additional "Provides: kernel-module-openafs", isn't that
a given, since the Name: is the same?)

%{kver} isn't a predefined macro, it should be passed at build time by
the buildsystem (since there could presumably be multiple kernels in the
build environment).

Thoughts?

~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!