AxelThimm/kmdls/kmods vs kmdls at a glance

Tabular summary: Comparing kmods and kmdls

Is something is unclear please check the detailed comparison .

The rating is + for kmdl, - for kmod, 0 neutral. More important parts and larger differences get more symbols.

Feel free to add your own rating column.

	kmods	kmdls	at's rating
			features
kernel/kabi's id	merged with the module's evr	embedded in name
specfiles/src.rpm	two, split for userland vs kernelland	one
helper applications	kmodtool	none
kernel agnostic	no, wants to become	yes
kernel flavour agnostic	no, wants to become	yes
design/flexibility	interface is implementation	interface/implementation abstraction
bundled flavour builds	yes	no
		comparison: rpm	+++
rpm	breaks on rpm level, no fix possible	like conventional packages	+++
rpm -U	does not work	(see above)	already rated above
rpm -i	does not work	(see above)	already rated above
$1 in scriplets	does not work	works	++
		comparison: yum and other depsolvers	+++
w/o plugin and new kernels	installs the kmod for the latest kernel	no coinstallation for new kernels	--
w/o plugin and module upgrades	file conflicts on test transaction	proper upgrading	+++
w/ full plugin support (best case)	only one kernel supportable, no updates for other kernels, can even deactivate/remove kernel modules from other kernels	all kernels get full support	+++++
other depsolvers (smart/apt)	require special handling as yum	trivial pluginization, in works	+
		comparison: short-term maintenance/development	+++++
further yum development	needed for fixing the above	none needed	+++++
debuginfo support	no changes	part of macros	0
rpmbuild		no changes	0
mock, mach, etc.		no changes	0
buildsystem repomanagement		needs special handling (what kernels to support, what flavours exist, cleaning up old kernel modules when cleaning up kernels from repo)	0
		comparison: long-term maintenance	++
infrastructure	needs two bugzilla/owners/scm folders How does user know whether a bug is in userland or kmod?	like conventional packages (just one entry)	++
rebuilds for new kernels (often)	every new kernel needs specfile/src.rpm changes	specfile/src.rpm/userland invariant	++
rebuilds for new flavours (seldom)	full rebuild of every other flavour	specfile/src.rpm/userland/other flavours invariant	+
		comparison: standardization	+
existing standard of Fedora	yes	no	--
Other distributions	-	runs on RHEL4/3, FC1-6, RHL7.3-9	++
Cross distribution standard	-	aims to become one already tested on Mandriva, would work on SuSE	++
support different implementations still same specfile/src.rpm	-	yes	+
		comparison: flexibility	+++
debuginfo bundling and flavour builds	all kmods share one debuginfo => need to always bundle (re)builds of all flavours	each kmdl has its own (re)builds for kernel/flavour separate	+
kabi support	none	already supported by interface no specfile/src.rpm/userland changes	+++
custom kernel support	only if 100% like a Fedora kernel (including name conflict) forces custom kernels to violate no-replacement-of-core-packages	full, in practice since several years	++
		comparison: current investment and experience	---
procedures to become a Fedora standard	all finished	trying to convince Fedora pricipals	---
existing kmods/kmdls in Fedora	yes, only one, but half a dozen in queue	none	--
existing kmods/kmdls in 3rd parties	half a dozen at livna	several dozens at ATrpms	+