Attention kernel module project packagers!

Josh Boyer jwboyer at jdub.homelinux.org
Tue Aug 15 12:51:48 UTC 2006


On Tue, 2006-08-15 at 14:34 +0200, Axel Thimm wrote:
> Hi all,
> 
> there is currently a discussion about replacing the current kernel
> module scheme ("kmod") with a new one ("kmdls"). This is because the
> current scheme has some unfixable flaws. The proposed new scheme is
> the one used at ATrpms, so if you ever used a kernel module package
> from there you know how it is setup.
> 
> The kmdl approach has several nice features other than being resistant
> to the design issues of the current setup.
> 
> * It is an interface/implementation design that can actually even be
>   used for the current (broken) setup. The specfile remains invariant.
> 
> * It uses one specfile/src.rpm for both userland and kernel modules,
>   e.g. one set of sources/patches/changelogs/bugzilla entries/owners.
> 
> * It is kernel and kernel-flavour agnostic, the same specfile/src.rpm
>   can be used for any kernel/flavour combination, even for such that
>   are yet to come.
> 
> * Has full yum-support with a 99-line python plugin, works even w/o
>   the plugin with a couple more keystrokes.
> 
> * Is field-proven for several years and managed to never have to
>   change the interface!
> 
> More details are on http://fedoraproject.org/wiki/AxelThimm/kmdls
> 
> It is important for FC6 and RHEL5 to make a decision on adopting
> it. Currently GFS is being packaged in the old scheme which is known
> to exhibit several flaws.
> 
> An argument against adopting kmdls presented by Thorsten Leemhuis is
> that
> 
> * it's too late now to fix it, we should live on with kmod bugs for
>   RHEL5's life-cycle (ending 2012 ...)

Fedora is _not_ RHEL.  Period.  If they happen to use the same packaging
scheme for modules, fine.  That doesn't mean that Fedora cannot change
it's standards during a particular RHEL's lifetime.

Therefore, I see no urgency in getting this changed.  If kmdls is truly
a better way, then it can be adapted when it has been fully discussed.

josh




More information about the devel mailing list