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

[Fernando Pablo Lopez-Lezcano]

> > IMHO the problem of users picking up the wrong package should be solved
> > with proper dependencies so that it is not possible to install the wrong
> > package at all.
> 
> SMP users often have the UP kernel installed, too. Since ALSA is optional,
> you cannot force them to install kernel modules for both SMP and UP
> kernel. In case they pick the wrong package (because they don't pay
> attention to the "smp" in the package name), it won't work.

Well, then I think they should learn :-). Users can download all sorts
of wrong packages for what they want to do, not just kernel modules.
Sorry, but I really think that correcting this type of user error
(picking the wrong package) in this way is a mistake. The solution is
not generic and it does not REALLY solve the problem. The user can still
pick the package with the wrong architecture. So what's next, packaging
all architectures and support for all kernels (why just smp?) together?
YUCK!!

The solution is to provide a way to download and install packages that
only presents the user with choices that are appropriate for the kernel
and architecture that are installed in his machine.  

> > If you try to install a particular kernel module and the
> > matching kernel for it is not there, RPM should refuse to install it.
> 
> Of course.
> 
> > If you try to install the wrong architecture RPM should refuse to install
> > it.
> 
> Do you suggest putting the %arch into the package name, too?
> (I don't see the kernel rpm provide anything like that, though)

Not in the name of the package. The problem of mismatched architectures
for kernel modules is real and the only reliable solution I found (while
packaging ALSA for Planet CCRMA) is to include proper provides in the
kernel packages so that a kernel module can only be installed if the
proper kernel with the proper architecture is installed. 

The kernel package provides:
Provides: kernel-version-%{_target_cpu} = %{version}-%{release}
or 
Provides: kernel-version-smp-%{_target_cpu} = %{version}-%{release}
or whatever, and the kernel module can "Require" it ensuring rpm can
match the proper architecture. Always. We have a dependency database. We
should use it. 

This obviously requires those provides be provided by the kernel. Could
kernel packagers please consider adding something like this? I don't
care about the names but the functionality should be there. Please?? 

> > This means no shared up and smp modules in the same package. Each
> > package has the modules that are needed by one and only one kernel
> > (which BTW is in its own package). 
> 
> 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). 

-- Fernando