AxelThimm/kmdls/kmods vs kmdls at a glance
From FedoraProject
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 | + |
