Re: Bug#2697: symlink /usr/include/asm in libc5-dev
> Sorry about not letting this die out, but I have been thinking
> about this issue since my last message. You say that you are going to
> include both /usr/include/asm-i386 and /usr/include/linux in
> libc5-dev now. (aside: which kernel do these come from?)
The are currently from 1.3.64, which is the latest includes package
that I have.
> I guess the pro is that everybody's development environment
> (wrt.headers, at least) is locked in, and one may be able to
> predict/reproduce compilations since all header files are the same.
Exactly. This issue comes up on the linux-gcc list every so often.
As usual, there was no resolution when it came up a couple of weeks
ago, but there was considerably more support for doing it this time
around. So much so that H.J. Lu said he would probably do it when he
gets more disk space later this year.
When libc 5.2.18 was recently broken by changes in the ~1.3.62 kernel
headers and again (albeit temporarily) in ~1.3.81, I decided to go
ahead and include "approved" headers with libc for Debian regardless
of what H.J. Lu does. It will remain this way as long as I'm
maintaining libc, which I hope is still on an interim basis.
> But then, if ever there is a new kernel (either a new debian
> package, or something that the user picks up herself) which has an
> improvement/modification of the kernel headers, then one can't use it
> unless one blows away the two directories from libc5-dev, and
> installs two new symlinks. Unless, of course, the libc-dev package is
> synched with the kernel packages (bletch!).
First, the libc5-dev package will be updated periodically to recent
kernel headers. Not counting bug fixes, this will probably be done at
least once before the real release of Debian 1.1.
Second, in my experience, very few programs actually need the very
latest kernel headers. For those that do, you can just use the
appropriate -I/usr/src/linux-X.Y.Z/include in your CFLAGS.
> The fact that it may be a newly uploaded kernel sources debian
> package means that hacking away in /usr/include should not be
> required (I mean, if you get your own kernel, maybe we could say you
> are on your own, but a bona-fide debian user upgrading packages
> should not have to hack in /usr/include).
They won't have to hack away in /usr/include. The kernel will
continue to ignore the headers in /usr/include and use its own, just
like it has for ages.
> The fix is simple: on a debian system, at least one where the
> include files are to be used, one is certain to have kernel-headers
> (part of the includes or sources package, or whatever they are
> currently called), so that ../src/linux/include/asm and
> ../src/linux/include/linux are guaranteed to be there. A depends
> line can doubly ensure that, but we'll have to check circular
> dependencies, though I doubt that kernel sources/headers depend on
> libc-dev.
That is how it was done for a long time, and with good reason. Times
have changed though, and the problems caused by doing it that way are
greater than than those that are fixed.
> Poof. People can use whatevr kernel they want, libc-dev is no
> longer synched with the includes/sources packages, and libc5-dev gets
> smaller too.
People can still use whatever kernel they want.
David
--
David Engel Optical Data Systems, Inc.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Reply to: