[Pkg-lirc-maint] Bug#436166: Bug#436166: Bug#436166: Progress notes

[Andrew Moise]

On Fri, Mar 28, 2008 at 1:42 PM, Stefan Lippers-Hollmann <s.L-H at gmx.de> wrote:
>  If you look at the history of this bug, it had be reassigned to linux-2.6
>  in august 2007 (and re- reassigned to lirc ~2 weeks later after talking
>  to linux-2.6 maintainers).

  Ah yes, I should have seen that.  It looks like Julien believed that
the problem was a _userspace_ application including bttv.h, not a
kernel module depending on a header that isn't part of linux-headers
for some reason.  If the lirc userspace tools want to compile against
bttv.h from the kernel, that's a separate issue with a separate
solution.
  I still have the feeling that I'm missing something -- it seems like
including a header in linux-headers, if there are Debian-packaged
kernel modules that need it in order to build, is such a no-brainer
that I must be misunderstanding what's going on :-/.  That's true even
if the headers are not part of any legitimately exported kernel API.
  I mean, the whole "breaking Linux headers out into a separate
package so that kernel modules can compile against it even if they
_think_ they need to compile against a previously-built kernel source
tree" idea is a Debian-specific construct, with nothing to do with the
upstream kernel, right?  I just don't see any sense in which bttv.h
should be considered "private" and not provided to a kernel module
that wants to compile against it.
  Again, I must be missing something.

>  In the end this bug is totally unimportant as long as #471383 remains
>  unfixed, which prevents lirc_gpio from compiling at all with recent
>  kernels (2.6.23, 2.6.24).

  I agree with all of this and what follows completely -- it sounds
like not compiling lirc_gpio at all might be a good way to kill two
birds with one stone :-).  If upstream isn't keeping it working with
modern kernels, then I don't see much reason for it to hang around
causing problems for the other modules in the Debian package.
  Cheers.