AxelThimm/kmdls/kmods vs kmdls at a glance

From FedoraProject

Jump to: navigation, search

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 +