Attention kernel module project packagers!

[Fernando Lopez-Lezcano]

On Tue, 2006-08-15 at 09:27 -0400, Jesse Keating wrote:
> On Tuesday 15 August 2006 08:48, David Woodhouse wrote:
> > I think this argument is invalid. We should ban _all_ module packages
> > from Core and Extras anyway.
> 
> I'm with David on this one.  Packaging of modules is the path to insanity.  It 
> requires all kinds of weird hacks to how they are built, how they are named, 
> how they are handled by rpm and depsolvers, they always lag, they always hold 
> users behind when critical kernel fixes come out, etc, etc, etc...

Sorry. No. Not "always". Always is _always_ too strong a word, oh well,
perhaps not? :-) ;-) :-)

ALSA: I've been packaging ALSA kernel modules for years for the Planet
CCRMA project (since 2001). Bumped my head against many walls in the
process. Examined kernel packaging proposals that sounded fine till you
used them and found they did _not_ work. I packaged kernel modules first
out of necessity because the kernel did not include ALSA at all. Then
also out of necessity to get newer versions of the ALSA kernel modules
than the ones in the standard kernel tree - or modules for soundcards
that have not made it to the kernel tree yet but are usable (and no,
waiting for them to make it to the standard tree is not always an
option).

I'm not arguing for or against including kernel modules in extra or core
or rhel or whatever - but there should be a solid guideline on how to
package them that works. With proper support in resolvers, kernel
infrastructure, etc[*]. If the current one has flaws (it does!) then
let's fix them. The need exists, it is part of reality, denying reality
will not make it dissappear (that's at least my experience over the
years). 

I'm still using in Planet CCRMA a scheme similar to the one proposed. It
works. 

-- Fernando

[*] even support for the kernel itself has problems - if I have a kernel
that is version-release older than the latest kernel I _can not_ install
it using an unpatched yum. 


> I personally feel (as does David) that if the module isn't good enough for 
> upstream, then it would HAVE to live in the kernel package itself.  If it's 
> not good enough for the kernel package itself, then it isn't good enough for 
> Fedora.  (Same could be applied to RHEL, but that's a battle for a different 
> list).
> 
> Arguing over which ugly ass hack to apply to be able to package kernel modules 
> is a bikeshed argument.