[ltp] Packaging tp_smapi using module-assistant?

[Shem Multinymous]

Hi,

On 8/10/06, Andrew Barr <andrew.james.barr@gmail.com> wrote:
> is if there would
> be any way to package tp_smapi as a kernel module (using
> module-assistant) and therefore allow users to continue using the
> official Debian (or Ubuntu, should demand be there) kernel images?

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).
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.

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.

The long term solution is to have the thinkpad_ec and hdaps components
of the tp_smapi package merged into mainline (but see the recent mess
on LKML or hdaps-devel).

  Shem