[Pkg-lirc-maint] LIRC 0.9 backport to go with backported Linux kernel?

[Stefan Lippers-Hollmann]

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+
- several RC_CORE kernel drivers replacing their out-of-tree 
  counterparts from lirc-modules-source require an updated v4l-utils
  package (ir-keytable, to be exact), not present in squeeze for 
  configuration (button assignment).
- /var/run/ --> /run/ transition, which requires exact versioned 
  conflicts.
- the socket location has changed from /dev/lircd to /run/lirc/lircd,
  given that the inputlirc package mimics liblircclient0's ABI, this 
  breaks in a squeeze environment (#617523). Fixing this would require 
  an updated inputlirc package, which in turn would be incompatible 
  with plain squeeze.
- 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)
- configuration for the lirc dæmon changed significantly (long overdue 
  debconf removal) - and will change even more, due to the totally 
  different environment lirc has to cope with in wheezy, using 
  in-kernel RC_CORE support (refer to RC bug #655969, this has been 
  implemented in svn already[1], but is still lacking a guided config 
  transition attempt - pending).
- removal of lirc-svga binary package
- the init script now expects, and requires, access to /sys/class/rc/ for 
  several devices (those which support different protocols at the same
  time (like {,lirc-}mceusb{,2}), in order to switch them to their 
  preferred/ configured userspace protocol. This functionality requires
  RC_CORE subsystem support from the kernel (>= 2.6.37).
- due to afforementioned configuration changes and changed kernel 
  module names, autoloading of lirc kernel modules is no longer 
  existing, needing manual adaptions.
- liblirc_client.la removal, conflicting with several packages (versioned 
  Breaks, these are fixed in wheezy) in squeeze.
- lots of reasons I might have forgotten at the moment.

Therefore you really want a complete wheezy environment for kernel >= 
2.6.37 and lirc 0.9~, trying to backport these changes to squeeze/ 
squeze-backports would be a nightmare and make the several versioned
package relationships significantly more complex. Personally I cannot 
imagine any backported packages that would work in squeeze (kernel 
2.6.32) and squeeze-backports (squeeze + kernel 3.2), without breaking 
either and numerous other userspace packages (inputlirc, v4l-utils, 
kradio). Even if such a package would be possible, it would require 
several further updates for squeeze-backports and significant 
modifications that would never meet backport criterias (cooking up a 
package that does not correspond to anything that ever was in testing/ 
unstable).

lirc 0.8.3-5 is functional in squeeze (kernel 26.32) and I'm trying my 
best to get a "perfect" lirc 0.9 into wheezy (still a couple of  
changes pending). The squeeze --> wheezy dist-upgrade will require 
manual configuration changes for several devices, which I'm still 
trying to ease for most users. But squeeze-backports is something that 
(imho) can't be supported sanely (due to the massive upstream changes)
at all. This situation is looking better for an upcoming 
wheezy-backports - likely even avoiding a need for backporting 
alltogether, but even there is a potential of breakage for kernel 
modules still stuck in staging (lirc_bt829, lirc_igorplugusb, 
lirc_imon, lirc_parallel, lirc_sasem, lirc_serial, lirc_sir, 
lirc_ttusbir, lirc_zilog).

Regards
	Stefan Lippers-Hollmann

[1]	http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-lirc-maint/attachments/20120415/174807ed/attachment.pgp>