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

Stefan Lippers-Hollmann s.L-H at gmx.de
Fri Mar 28 18:10:29 UTC 2008

On Freitag, 28. März 2008, you wrote:
> 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-lirc-maint/attachments/20080328/84425c5b/attachment.pgp 

More information about the Pkg-lirc-maint mailing list