On Freitag, 28. März 2008, you wrote: > On Fri, Mar 28, 2008 at 1:42 PM, Stefan Lippers-Hollmann <[EMAIL PROTECTED]> > 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.
The decision which headers get shipped in linux-headers-$KVER is basically made upstream by the mainline kernel developers, who are investing a lot of time to clean up the userspace (and kernel) visible API. cf. http://svn.debian.org/viewsvn/kernel/dists/trunk/linux-2.6/debian/rules.real?rev=10983&view=markup in the install-headers_$(ARCH)_$(FEATURESET)_$(FLAVOUR) target. > > 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. This is definately not a preferred "solution", but may be a potential result unless a fix can be found. Truth to be told, the required changes are not simple
signature.asc
Description: This is a digitally signed message part.
