Re: Bug#2697: symlink /usr/include/asm in libc5-dev
> Yes, but locking in a specific set of headers via libc5 will have no
> effect on this problem. If a user installs a kernel newer than the
> one whose headers libc5 is insisting on, and if the newer kernel's
> headers have changed in some substantial way which breaks some
> program(s), then those programs just *have* to be recompiled, with the
> newer headers. Forcing the older headers in libc5 won't solve the
> problem. In fact this will just aggravate things since even if the
> user gets the source package and recompiles it themselves, libc5 has
> arranged it so that the package will still be compiled with the older
> *incompatible* headers.
You don't understand. Installing a new kernel will not break programs
that are already compiled. What it can break, and occasionally does
break, is the ability to recompile programs. I've already given the
example of libc itself being broken twice by recent kernel changes.
Another prime example are the networking programs. The old ones won't
compile with new kernel headers and the new ones won't compile with
old kernel headers.
> Now you can complain that the kernel people should minimize the number
> of times they change their user visible data structures in an
> incompatible way, but that's another issue.
No, this really is at the heart of the issue. In an ideal world, the
kernel and libc developers would closely coordinate their changes. If
one group made an incompatible change, the other would make the
corresponding change and the two would be released together. This
doesn't happen and because of what I'm doing, doesn't have to happen.
> Maybe I misunderstand the problem we are trying to solve. Is it
> source packages that compiled fine on one user's machine, but wouldn't
> on another's? Binaries that break when the user upgrades their kernel
> to an incompatible version? something else?
The former, but it's worse than that. Source packages that compiled
fine on a user's machine one day won't compile the next day on the
very same user's machine.
> Anyway, I have had very few problems on the whole with all the
> kernels. However I could forsee real problems if I install a new
> kernel that's not quite compatible with the headers that libc5-dev
> insists on, and then have the programs I'm developing for my research
> break when I recompile them.
The vast majority of user's programs don't need the very latest kernel
headers. If you are one of the very few who do need the latest kernel
headers, adding -I/usr/src/linux/include to your CFLAGS will get you
the old behaviour. What's so hard about doing that? Also, don't
forget that our libc will be updated periodically to use recent kernel
headers.
> In the past, there have been kernel problems. xntp was completely
> broken for a long time under newer kernels, but that just meant that
> it needed to be fixed, not that it needed to provide it's own headers.
It depends on how xntp was broken. If it used a kernel interface that
changed, then yes, it would have to be updated accordingly. However,
if it broke simply because the new kernel headers were incompatible
with the libc headers, then it's a completely different issue, and the
one I'm trying to address.
> Just from an asthetic perspective, to my mind, the system headers
> belong in the source package, and libc5 should always be compatible
> with the headers in Debian's current official source package. If the
> user then installs a newer kernel, essentially a newer "source",
> caveat-emptor. Of course this would mean that all people compiling
> programs would have to have source installed, but if that's too
> onerous, then we *should* probably have a separate kernel-headers
> package which is synced with source.
That's what we used to do, but without the coordination between the
libc and source/includes package maintainers. The new approach is
simpler because it doesn't require that coordination.
> D> If the approved kernel headers are supplied with libc,
> D> you can definitively say that something compiles with libc-X.Y.Z-R.
> D> If we go back to splitting out the kernel headers, then you have to
> D> qualify things further by always adding well, at least with
> D> kernel-A.B.C-S.
>
> Does this really affect the average user? I don't even think that
> most developers compile most of the packages on a regular basis. We
> can include a debian.compile-notes in packages if necessary to provide
> this info.
Yes, it affects average users. They gain a stable development
environment that doesn't change from day to day simply because they
upgraded kernels. It also tremendously helps the libc maintainer,
currently me. If a user reports a bug about something not compiling
with some revision of libc, I know exactly which kernel headers were
being used. I don't have to follow up with "Which kernel headers are
you using?" and then go find that same version in order to recreate
the problem.
> Hopefully I understood the situation enough for this to be
> useful/meaningful.
I've been through this discussion several times and have heard all of
the pros and cons. Hopefully I've helped you understand what I'm
trying to do.
David
--
David Engel Optical Data Systems, Inc.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Reply to: