Kernel module packages (was - Re: Pre-Review: Asterisk)

[Tom 'spot' Callaway]

Two replies, one email. What a deal!

On Sun, 2005-04-03 at 14:56 +0200, Ralf Ertzinger wrote:
> On Sat, Apr 02, 2005 at 04:56:01PM -0600, Tom 'spot' Callaway wrote:
> 
> > I agree. External modules are a given kernel specific. They should
> > identify which kernel they are for.
> > 
> > However, this should not be done in %{name}. Version is a more
> > appropriate place for this.
> 
> RPM does currently not provide an appropriate place for this information,
> that's the whole problem. Sticking it in %{name} is the least ugly approach,
> IMVHO, but still quite ugly.

Of the three places we could put it, %{name} is the worst.

Just imagine if we have builds for 20 different kernels. And you do "yum
search kernel-module-foo". You're going to get 20 unique results.
Bugzilla? 20 different entries. CVS? 20 different branches.

We should treat name as exactly that, its name, not overload it with
qualifiers.

> I think we will need a new mechanism for this, with (at least) one new field
> in the RPM headers.

This is probably too much. Every tool on the planet will break if we
change the %{name}-%{version}-%{release} scheme.

> One question: is this problem confined to kernel modules? Or are there other
> packages out there which may benefit from this? I read in Mike Harris' blog
> that RH has an internal CVS version of xorg which allows parallel installation
> of multiple X servers. Would this mechanism be useful there, too?

It's possible. I'm not familiar with his xorg system, but it would run
into the same upgrade issues if he tried to make a change to both
variants. 

On Sun, 2005-04-03 at 14:21 +0200, Thorsten Leemhuis wrote:
> I don't really like this idea. The version of the kernel-module needs
to
> be somewhere because it is of interest sometimes -- especially with the
> ati and nvidia X-drivers. Example: nvidia driver version 1.0-7174 will
> only work with 3d-accel when the kernel-module is compiled from the
> nvidia-1.0-7174 package, not with modules compiled from older ones (e.g.
> 1.0-7167). This maybe could be solved by a
> Provides: kernel-module-nvidia-glx-version = 1.0-7174
> 
> in the kernel-module-nvidia-flx package and a 
> Requires: kernel-module-nvidia-glx-version = 1.0-7174
> 
> in the nvidia-glx package, which contains the graphics driver itself. 
> 
> Okay, something similar could be achieved by a
> Requires: kernel-module-nvidia-glx = $(uname -r)-release
> in the driver-package. But tracking which kernel-module release is build
> from which "source" is rather confusing this way imho (and makes
> debugging in a case of an error hard). Also in this case the driver
> package would have to be rebuild on each kernel-update. So it's a no go
> afaics.

OK, I'm not entirely sure how:
rpm -q kernel-module-nvidia-glx --provides | grep kernel-module-nvidia-glx-version
is all that confusing. :)

However, if the consensus is that the version number needs to appear in the n-v-r, we could 
overload the %{release} field with that information.

So:
Name: kernel-module-foo
Version: 2.6.10_3smp
Release: 1.0_7174.1

But, in the driver package, you'd still have to use a:

Requires: kernel-module-nvidia-glx-version >= 1.0-7174

And Provides: that field in the kernel-module package.

So, here's my handy checklist:

- Does the end user care about the module subversion? Probably not. (And
if they do, its easy to document how to find it for any kernel-module-*,
we can standardize a "kernel-module-%{name}-version" provides as a
mandatory spec item.)

- Can we track the module subversion using internal provides? Yes.
Unlike your statement above, a driver package rebuild would not be
required on each kernel-update, since the Requires is a >=. If the
driver needs "at least" that version of a module, the >= works. If the
driver needs to match the kernel module version exactly, then you need
to rebuild on updates that change the kernel module version number, but
not for minor fixes such as bugfixes to open source code (that don't
consist of upstream version updates).

- Then, does the kernel module version need to show up in the n-v-r? I
say no.

But again, if all the people packaging kernel modules say yes, we can
overload the %{release} field. It just won't help your dependency
checks.

~spot