As per bug 54518, lirc support was dropped from the gentoo-dev-sources package. Comment #2 states that this driver can be built independently of the kernel and suggest that someone contribute a package for it. Bug 54592 is now tracking a request to add driver support to the existing lirc package. It would have been nice if this package was added *prior* to removing support in gentoo-dev-sources as people who were depending on that package are left "high-and-dry" until bug 54592 is resolved. In the future, if moving support for something from one place to another, please ensure the alternative is in place prior to removing support from the original location. That way a clean transition path is available for people currently dependeing on the "moved" functionality. Reproducible: Always Steps to Reproduce:
I agree, Dalton, that sort of thing is definitely NOT the way to keep quality. However, it's not (yet?) a DevRel issue, so I'm reassigning to the kernel team who removed the support in the first place.
lirc support was removed because: - it was broken. - the developer did not want to work with the kernel developers to get the code into the mainline kernel (due to lack of time on his part.) - no one wanted to maintain it for newer kernel releases. - it was broken. Oh, did I mention it was broken? So, that is why it was removed, along with a lot of other things that can be standalone packages if anyone really wants to. I am trying to make a kernel package that we can maintain, and that follows the mainline kernel.org kernel quite closely (this allows us to pick up their fixes easily, and to get support from them.) If we add a lot of other patches to our tree (like lirc) the kernel.org community will not support us.
Please be aware this was _not_ a request re-add support for lirc to gentoo-dev-sources, nor is it restricted to the lirc patch. This is also not questioning the motives for removing lirc patch (or anything else) from the kernel as I'm sure they were justified. I don't understand your apparent hostility regarding this issue. The request is if you want to move a current kernel patch to a stand-alone package, please try to make sure the stand-alone package is available first. If the software in question is broken, the new package can be masked so that dependent users can monitor the situation (via some bug#). Don't just yank the rug out from under your users who are currently depending on the patch and say "This can be a standalone package. If anyone really wants it, go create the package. You're on your own." By virtue of the fact the patch had been there, obviously some portion of your user community wanted it, was depending on it, and now does not have it. I appreciate you're trying to improve the package by making it more maintainable, but what's the use of having a maintainable package if your users can't trust you not to abandon them when something becomes inconvenient?
lirc has been provided in portage as an external module (emerge lirc) since long before we removed it from gentoo-dev-sources. If there are any other modules you are missing then please reopen this bug and let us know (but I don't think there are).
I just wanted to let you know that lirc module support was provided for 2.4 series kernels prior to the removal of that patch from gentoo-dev-sources, but not for 2.6 kernels. 2.6 support was not added until bug 54592 was resolved (a good while after the removal of the patch). If the lirc package supported 2.6 modules prior to the removal of the patch, this would have never been an issue (and is indeed the core of my request).
