Re: Fixing the lm-sensors/i2c mess
David Z. Maze wrote:
lm-sensors 2.7.0 built sanely against i2c 2.6.x, right, so it works
with a stock 2.4.x kernel. That particular version of lm-sensors has
the issue that the userspace library's ABI changed but the library
soname didn't (hence the libsensors-1debian1 package that existed for
a bit and plagued testing KDE users); I don't know whether it's the
same library as libsensors2 or not.
Looks like it has the same userland ABI as libsensors2, judging by
sensors.h. (I haven't checked any other header files, and I would guess
that this needs testing.)
Think you could try packaging 2.7.0, hacking it to produce libsensors2
rather than libsensors-1debian1?
Then build it with a stock 2.4.x kernel (i2c 2.6.x). Then test to see
whether it works with current ksysguard in unstable without KDE
recompilation (which would prove that the ABI was the same). I'd be
happy to help with these two steps.
I would recommend, if you end up going this direction and it works,
creating two source packages (better package names are welcome!):
lm-sensors-old for linux-2.4
This would be the package of lm-sensors 2.7.0 described above.
It would provide a libsensors2-old package (containing libsensors.2.so),
the lm-sensors-source package, and possibly sensord-old (if needed;
perhaps new sensord will work with old libsensors).
lm-sensors-new for linux-2.6
This would be the package of lm-sensors 2.8.2+, for use with kernel 2.6
(once it's ready to do so). Since all the modules are built in to
kernel 2.6, it would be userland tools only. It would provide a
libsensors2-new package (containing libsensors.2.so), libsensors-dev
(clearly one should develop against the new version), and sensord-new.
The two libsensors2 packages would then conflict with each other; one
would be for 2.4 kernels only and the other would be for 2.6 kernels
only. (Which isn't perfect, but it's not bad either.)
I think this would needed because I think the change in the modules ABI
requires different versions of libsensors for the different module
versions. Someone correct me if I'm wrong.
The other option is the 'just document it' option, which I already sent
fixes in support of.
Any thoughts, plans, etc.? I would hope to get this mess fixed within a
month due to its effect on KDE (w/r/t getting KDE into sarge).