Re: Bug#2697: symlink /usr/include/asm in libc5-dev
> > 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.
>
> I prefer to have the links in /usr/include and I think I'm
> not the only one.
We have yet to hear from the silent majority.
> What do you think about splitting libc5-dev
> in libc5-dev containing the normal include files (with linux
> and asm as symbolic links to the kernel header files) and
> a libc5-devk containing the linux and asm directories with
> the header files from an "approved" version. libc5-devk could
> then depend on "source|libc5-dev" and libc5 should recommend
> "libc5-devk (>=vers.)|source".
I don't really want to add anymore packages. First, the current
packaging is already bordering on being too granular. Second, this
won't fix one of the major problems I'm trying to fix -- that being
programs breaking from week to week only because the kernel headers
changed. If the approved kernel headers are supplied with libc, you
can definitively say that something compiles with libc-X.Y.Z-R. If we
go back to splitting out the kernel headers, then you have to qualify
things further by always adding well, at least with kernel-A.B.C-S.
> Using two libc5-dev* packages has two advantages. It makes
> people happy that prefer to have links in /usr/include and
> it would make it much easier for you to upgrade the kernel
> header files (no need to update libc5-dev!).
Is it really that painful to add a -I/usr/src/linux/include to CFLAGS
for those very, very few programs that might need it? That being
said, what I might consider doing, and I emphsize *might*, is tweak
the installation such that existing /usr/include/{asm,linux} symlinks
would be left alone. If I did that though, I certainly wouldn't
document it and I would also discourage it's use every chance it came
up.
David
--
David Engel Optical Data Systems, Inc.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Reply to: