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

[Matthew Miller]

On Wed, Jun 29, 2005 at 08:38:45AM -0500, Tom 'spot' Callaway wrote:
> > 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.

That can work too -- look at the pump RPM, which only generates subpackages
with different names. But I only think this is preferable to putting the
package release number in the version -- my preferences is for kernel and
package release number to both go in the release.


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

Right -- anything that wants to do something smart with these packages will
have to be smart about it. I think it's better to require whatever smartness
in as few places as possible, even at the price of requiring more of it in
those places. Redefining what 'version' means to mean "somes the upstream
version, sometimes some numbers we made up" seems a lot worse in general.

And, the "cleanver" thing to get rid of the '-' already requires some
parsing. As much as I hate _ in package names, we could do:

Release: %{realpackagerelease}_%{cleankver}

or maybe

Release: %{realpackagerelease}.kver%{cleankver}

(Ugh, very long and ugly, though.)


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

The more I think about this (Jack's) approach, the more I feel okay about
it. Maybe it's contagious. :)


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

That seems backwards. Right now, the kernel modules are a subpackage of
the openafs package -- making the package kernel-module-openafs seems like
putting the cart before the horse. (Why would openafs-server be a subpackage
of that, for example?)

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

Except, if we're building for five different kernels, each of those would
then generate the identical openafs-server, openafs-client, and openafs
packages. At the very least, that's a lot of wasted CPU.


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

Ow, must we?

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