[ltp] Packaging tp_smapi using module-assistant?

[Andrew Barr]

On Thu, 2006-08-10 at 22:39 +0300, Shem Multinymous wrote:
> I'm not very familiar with module-assistant, but generally:
> 
> Until recently, the only gotcha in packaging tp_smapi is the tp_smapi
> package needs to delete or overwrite the hdaps.ko provided by the
> kernel package (this is done automatically by the tp_smapi Makefile).

I think that it *might* be possible to use dpkg-divert to do this: it
would redirect the .ko file installed by dpkg from the offical
linux-image packages somewhere else
(e.g. /lib/modules/.../hdaps.ko.official) and then allow an e.g.
tpsmapi-modules-2.6.xx-1-386 package to have such a file without
overwrite errors. This would probably require some serious skills and
time in the Debian packaging department. But this DMI patch issue
probably makes it a moot point.

> One way to tackle this is to simply not include hdaps.ko in the kernel
> package in the first place (i.e., undefine CONFIG_SENSORS_HDAPS) --
> this may actually be a sensible thing to do, since mainline hdaps has
> some major flaws that are fixed by tp_smapi.

Well, I'm working around the official Debian kernel images so that's not
my decision to make.

> With recent tp_smapi there's an extra concern: tp_smapi depends on a
> patch ("[PATCH] DMI: Decode and save OEM String information") that is
> in -mm but not yet in mainline. If your kernel don't have this patch
> then the tp_smapi Makefile goes into fallback mode where the DMI
> information is obtained at compile time instead of runtime; this means
> the resulting thinkpad_ec.ko is suitable for use only on the specific
> machine it was compiled on.

Two questions:

What does this patch modify in the kernel? Would it be possible to
generate updated modules and use a technique like that described above
to deliver them to users' computers in a tpsmapi-modules package? Or
does it patch something that is in the bzImage?

I generate the patches by editing the Makefile to point to each of the
kernel trees (2.6.15, .16, and .17) and then run 'make patch'. Does this
include the DMI decoding patch in the resulting diff? I thought I saw
some output that might indicate that but I want to be sure.


Andrew