[elrepo-devel] kmod packaging cleanup for rhel-6

[Farkas Levente]

hi,
let me write a little bit longer summary and explanation about kmod
packaging.
i plan to write a few bugzilla entry as conclusion of this mail.
unfortunately all of my previous rhel-6 beta ticket was postponed in
bugzilla as:
------------------------------------
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.
------------------------------------
so it seems rh is too close to the final 6.0:-( but i hope we can do it
in a way to include in rhel-6 (ad do some hack to include in rhel-5 too).

first redhat/fedora didn't support kmod packaging. after that there was
a time when fedora start to support it and then again drop support it.
for this reason there are many different kmod packaging guideline. here
i try to collect the most important ones:
- Fedora Kmod packaging
  http://fedoraproject.org/wiki/Obsolete/KernelModules
- Rpmfusion
  http://rpmfusion.org/Packaging/KernelModules/Kmods2
  http://rpmfusion.org/Packaging/KernelModules/Akmods
- ElRepo
  http://elrepo.org/tiki/kmodtool-el5
  http://elrepo.org/tiki/kmodspec-el5
  http://elrepo.org/tiki/kmodtool-el6
  http://elrepo.org/tiki/kmodspec-el6
- Red Hat Driver Update Program guidelines
  http://dup.et.redhat.com/
- redhat-rpm-config:
  /usr/lib/rpm/redhat/find-provides.ksyms
  /usr/lib/rpm/redhat/find-requires.ksyms
  /usr/lib/rpm/redhat/kmodtool
  /usr/lib/rpm/redhat/macros
fedora guideline was the first and contains a lots of useful info, first
version of kmodtool etc. but written for fedora where kernel updates are
not kabi compatible with each others. a new kmod rpm needed for all  new
kernerl.
to solve these problems comes rpmfusion's akmod (which is imho a the
right solution for fedora), but not for rhel where all kernel are kabi
compatible.
elrepo's template and kmodtool based on Red Hat Driver Update Program.
unfortunately rhel's redhat-rpm-config's kmodtool and macros are not
really updated and therefore nobody really use it (even though it'd be
the natural solution and the recommended way by rh).

my goal is to update /usr/lib/rpm/redhat/macros in redhat-rpm-config in
a way to be able to use it by rh, elrepo and all 3th party developer
who'd like to build kmod rpms.

at the same time it'd be useful if yum can handle kmod rpm in the "right
way". and here i define "right way" that on an rhel system kmod packages
should have to updated ie. only one version of the same packages can be
installed (since all kernel are kabi compatible in a rhel release).
currently it's not the case:-(

let's start with this last one (it seems to be easier). the problem is
that kmod packages virtual provides kernel-modules (through kmodtool or
%kernel_module_package).

obviously there are two way:
- patch yum to handle kmod rpms as normal package.
  https://bugzilla.redhat.com/show_bug.cgi?id=572883
  https://bugzilla.redhat.com/show_bug.cgi?id=502140
  pros: - don't have to modify anything else (kmodtool, macros,
          spec files) and could be very simple
        - the same redhat-rpm-config (ie. kmodtool/macros) can
          be used on both rhel and fedora ie.
  cons: - in all rhel version yum should have to patched and never
          can use upstream version (or upstream found a better
          solution), but yum already contains dozens of patch in rhel.
 patch attached to https://bugzilla.redhat.com/show_bug.cgi?id=572883
 as: https://bugzilla.redhat.com/attachment.cgi?id=435745
- rename kernel-packages to kabi-modules (as elrepo do it now).
  pros: - don't have to modify yum
        - don't have to rebuild current rpms
        - can be done without redhat
  cons: - not conform to Red Hat Driver Update Program
        - not conform to Red Hat provided kmods
        - different repos will do rpms working different


now go back to the main kmodtool or %kernel_module_package problem.
there was long discussion about it:
http://lists.elrepo.org/pipermail/elrepo-devel/2009-August/000018.html
related bugs:
- wrong requires and buildrequires in kmodtool
  https://bugzilla.redhat.com/show_bug.cgi?id=583839
- weak-modules fails to create weak links when updating kmod packages
  https://bugzilla.redhat.com/show_bug.cgi?id=593504
- unknown
  https://bugzilla.redhat.com/show_bug.cgi?id=480415
after think about it i conclude the best would be to fix the
%kernel_module_package macro and drop kmodtool totally.
pros: - conform to Red Hat Driver Update Program
      - easier to make to configurable in the spec file
      - can keep the kmodtool for compatibility reason
cons: - would have to rebuild all rpms (but there is no kmod for el6)
      - can be done without redhat. it seem rh is very slow on this
        whole problem and it'd be useful to find a way.

why we use kmodtool at all? why not put all the kmodtool content into
macros? then kmodtool can be a simple one liner (as we did it in
mingw32-filesystem) to keep it for backward compatibility:
-------------------------------
eval "`rpm --eval "%{kernel_module_package}"`" '"$@"'
-------------------------------
of course here the biggest questions:
- how kernel_module_package should look like
- what's kind of parameters or macros can/should be used in it.
- can we migrate the shell script into a few marcos?

if rh refuse yum patch we can rename kernel-modules to the current
kabi-modules.
if rh refuse the new macros we can still rename kernel_module_package to
kabi_module_package and add it to elrepo-release as
/etc/rpm/macros.{kabi-modules,kmod,elrepo} (choose one).

another small (bug?):
- kabi-yum-plugins name:
  https://bugzilla.redhat.com/show_bug.cgi?id=612826

so comments, what do you think?
regards.

-- 
  Levente                               "Si vis pacem para bellum!"