Re: linux-kernel-headers foul-up
On Tue, 4 Nov 2003 20:36:21 +1100,
Rob Weir wrote:
[...]
> > Xine also fails to compile (ditto nvrec, a low overhead
> > recording program). My conclusion: all video applications
> > are affected.
>
> Eh? The only things that could possibly be affected are those
> using kernel headers because they need to access some to
> special kernel service, like the framebuffer. If you build
> mplayer/whatever without framebuffer support, it will not use
> the kernel headers at all.
Well, to get your tv card to wrok you need kernel level support.
So I can't compile mplayer with the new "headers" installed and
enable its TV viewing and recording features at the same time.
> > > And last question, if this new splitting stuff causes
> > > breakage who will solve this? is this a debian issue, a
> > > linux issue or should the sources of for example mplayer be
> > > changed?
> >
> > Actually I can see the benefits of splitting. For me the
> > problem was that the glibc team decided to use the broken
> > (tm) 2.6 kernel.
>
> As Colin said, this was neccessary for NPTL support. They
> should be completely backwards compatible.
I can't argue with that. All my other programs are running
without crashing. I'm talking about hassle-free compiling, which
is the most important part of the Debian experience.
> > Fixing the problem should be as easy as rebuilding the
> > linux-kernel-headers source by sticking in your own kernel-headers
> > (from your custom make-kpkg kernel) into ./include and perhaps
> > deleting the ./debian/patches directory.
>
> Do you know what will happen if you start mixing things with
> NPTL support compiled in with these programs? I don't.
Well they're userspace programs (all installed in
/usr/local/stow). So the worse I expect is a user program crash.
I don't run mplayer as root. Then again the parent post in
question was dealing with hacks. So "fix" was used in a relative
sense, kind of like fixing your fuzzy TV by kicking it. (Try it
sometimes, it does work. Just do kick it too hard.)
> > My proposed reportbug fix is to have linux-kernel-headers as
> > a virtual "provides" package. Then we could have separate
> > 2.2, 2.4 and 2.6 headers packages, the same way we already
> > have separate kernel packages for 2.2, 2.4 and the broken 2.6
> > kernel.
>
> These are for userspace, not kernel modules.
But they really don't work with some programs that must compile
against certain kernel features. And some programs do need to
use kernel level features or they won't work at all. How do you
for example disable the framebuffer feature for a framebuffer
video player (fbxine or fbtv). So if I want to compile a
full-featured mplayer I have to resort to some ugly, non-Debian
hack (cobbling together a private package containing the 2.4
headers so that I could easiy uninstall later). If there's a
kernel-headers package for 2.4 then I could install that to get
an elegant, Debian-sanctioned hack.
> The 2.5 kernel headers should work fine with any kernel at all.
> If there is a bug in them, it should be fixed, not replaced.
Well, I wasn't ranting about the kernel headers being
kernel-incompatible, which was kind of the point of my saying
that I managed to recompile my kernel because it doesn't depend
on whatever is in linux-kernel-headers (because it has its own
headers to worry about).
Reply to: