[Fedora-packaging] kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file

[Thorsten Leemhuis]

Hi all!

There are ways to many things to discuss with the current proposed
schemes for packaging kernel-modules. That's why I'd like to break it up
into pieces and give some details of the different implementation
details. I choose to start with the "One specfile approach vs. splitted
spec files" discussion because that's a bit easier to discuss then the
"uname -r" stuff where even I'm still unsure how to proceed.

Axel, could you please take a look at this? Did I miss anything (I
surely did)? I tried to concentrate on the technical details.

== 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 an enhanced
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 really big area where parts/ideas 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.