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/
Attachment:
signature.asc
Description: This is a digitally signed message part.