Nameing guideline for external kernel-modules in fedora(.us)

[Ville Skyttä]

On Wed, 2003-12-17 at 22:10, Fernando Pablo Lopez-Lezcano wrote:

> > It's like that currently. But with SMP and UP in a single package, it's
> > impossible to pick the wrong one. The package just gets larger.
> 
> And it is still possible to pick the wrong one (wrong architecture, or
> even wrong kernel, SMP and UP are not the only choices AFAIK). 

Agreed, bundling is ugly.  It would probably also result in trouble with
custom kernels.

About upgrade functionality, I see the FC1 up2date has

  pkgsToInstallNotUpdate[comment]=A list of provides names or package
  names of packages to install not update
  pkgsToInstallNotUpdate=kernel;kernel-modules;

Ok, so this is sort of obvious.  But it may be a slight PITA: suppose
kernel-module-foo-1.0-1 which "Provides: kernel-modules" is built for
x.y-z kernel and installs modules somewhere under /lib/modules/x.y-z. 
Then, we discover a packaging bug in kernel-module-foo so it needs to be
rebuilt bumping the release tag, or a new upstream version surfaces. 
When releasing the updated package without the kernel version changed
meanwhile, *boom*, conflicts.

Suggestions how this should be handled?  Install everything from
kernel-module-foo-i.j-k into fully versioned directories or filenames
(ie. %{name}-%{version}-%{release} included) somewhere so that the
conflicts don't occur, and ensure somehow that it is deterministic which
version is seen by insmod and friends if kernel-module-foo-1.0-1 and
2.0-1 are simultaneously installed for the same kernel version?  Eek...
I'm getting the feeling that the "kernel-modules" provision is really
only useful with packages whose life cycle is tightly bound to the
kernel's.

The current (somewhat unfinished) fedora.us guidelines basically stuff
the `uname -r` of the kernel into kernel module packages' %{name}, that
results in butt-ugly but functional naming which I believe is pretty
cleanly supported by all package managers out there, without any
additional magic.  Even the rpm CLI does the right thing with those:
when a real update to a kernel-module-foo package is made, we want the
package managers to grok it and upgrade from the previous version
instead of installing a new one alongside the old.  But when the same
kernel-module-foo package is rebuilt for a new kernel, we don't want
upgrade but install.  I think this is still a useful scheme, but it
smells like trouble if the up2date kernel-modules provision would be
tried to be used with it.

A whole different issue is cleanly tweaking modules.conf.  Think about
the possibility where we have kernel versions A, B and C installed and
kernel-module-foo for only A and C of those, possibly in fully versioned
dirs somewhere as guessed above.  Kernel B should not "see"
kernel-module-foo's modules.conf snippets.  Some raw thoughts about how
to handle this (surprise, a modules.conf.d -like structure using `uname
-r` some way): https://bugzilla.fedora.us/show_bug.cgi?id=503