[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LIRC 0.9 backport to go with backported Linux kernel?



On Sun, 2012-04-15 at 23:47 +0200, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On Sunday 15 April 2012, Josh Triplett wrote:
> > [CCing the maintainers of LIRC.]
> > 
> > squeeze-backports has a 3.2 kernel, which includes the LIRC drivers
> > previously shipped in lirc-modules-source in squeeze.  However, the
> > in-kernel LIRC drivers have a modified userspace interface that requires
> > LIRC 0.9 to work; LIRC 0.8 no longer works with the 3.2 kernel.  Thus,
> > using LIRC with the Linux kernel from squeeze-backports requires a
> > corresponding backport of LIRC 0.9.
> > 
> > Would you consider providing a backport of LIRC 0.9 for squeeze?
> 
> Due to numerous infratructural changes, in lirc, the upstream kernel,
> surrounding packages and lirc packaging, I don't consider lirc to be a
> candidate for backporting to squeeze.
> - lirc >= 0.9.0~ can only work with kernel >= 2.6.37, there is no 
>   compatibility with squeeze's 2.6.32 - even trying to reintroduce a 
>   (totally untested) lirc-modules-source would break several devices 
>   supported in plain squeeze or plain wheezy+

This is terrible.  Is it really not feasible to do a run-time check?  It
should generally be possible for stable userland to work with the kernel
from stable, testing or unstable, as there is otherwise no good way to
do upgrades.

If not, this incompatibility must be mentioned in the package
description.

[...]
> - several lirc hardware drivers changed module names and userspace
>   API (from traditional lirc, over IR_CORE to RC_CORE - thereby 
>   exposing a new dev/input API, instead of -or in addition to- the 
>   classic lirc API), when merged into the mainline kernel; this also 
>   affects the device nodes exposed to userspace (/dev/lirc0 --> 
>   /dev/input/event%d <-- unstable device node)
[...]

But this should be covered by liblircclient, shouldn't it?  Why would
this matter to applications?

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: