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

[Matthew Miller]

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.


[...]

Oh wait, something else I want to comment on --

> 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")


Ouch -- this won't work. The .1 here will be very very confusing. For
openafs 1.3.84, the _package_ release shouldn't be 1.3.84.1 or whatever --
it'll make it hard to match up to the actual source. I think this is *worse*
than putting the version in the name.

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}


'cause hey, that's what the Release tag is supposed to be fore*.

> %{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,

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


> 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.

Passed in in a loop from the buildsystem? That seems decent.

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.


[...]
> 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).

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.

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 78 degrees Fahrenheit.