One specfile approach vs. splitted spec file
Mainly a matter of taste. Some prefer the one specfile approach that's used by kmdls, other the slitted approach used by kmods. The differences:
- debuginfo packages for kmdls won't get created with the automatic stuff that rpm normally uses; a script/macro that is mainly a copy of the stuff that's used by rpm currently handles that (see https://www.redhat.com/archives/fedora-packaging/2006-August/msg00053.html); that could be easily integrated into the standard macros shipped by FC / RHEL
- the one-specfile approach needs some sort of mechanism to make sure that
- the userland part normally isn't build for i586 and i686 because that's normally unneeded
- the kernel-modules can't be build for i386 because there is no i386 kernel in FC)
This is realized by %if %else %endif constructs in the spec file with the "kmdl_userland" define (see http://fedoraproject.org/wiki/AxelThimm/kmdls for details), that needs to be set by the buildsys when rpmbuild is called to build stuff
- the buildsys must queue the rebuild of a kmdl srpm multiple times to get modules for all kernel flavours build in the kmdl case -- the kmods scheme can build all in one step. The variants and the kernel-version are currently hardcoded in the kmod standard because the Extras buildsys doesn't support passing the variants and the kernel version to rpmbuild call yet. Axel says that the kmod scheme is not "kernel {version,flavor} agnostic" due to this hardcoding. But this hardcoding currently allow us to build the kmods without other changes in the buildsys; kmdls can't get build without special support in the buildsys due to the needed "rebuild one srpm multiple times"
- the kmod standard has the disadvantage that there are multiple srpms (e.g. one for kernel 2157 and one for kernel 2174). But this way we make sure that the
Note: There is a real big area where parts of one approach could be moved over to the other and the other way around. E.g. kmods could get rid of the "kversion" in "%{RELEASE}" of the SRPMS and create the debuginfo packages manually just like kmdls do -- that would solve the "multiple SRPMS" problem. kmdls also could hardcode the kversion and kflavor stuff and use loops just like kmods -- then they would be buildable with the current buildsys.