Re: Bug#2697: symlink /usr/include/asm in libc5-dev
>>>>> "D" == David Engel <david@elo.ods.com> writes:
First of all, let me preface this by saying that it's entirely
possible that I don't fully understand the problem, but I'm going on
anyway, and I'm sure people will correct me when necessary.
D> I don't really want to add anymore packages. First, the current
D> packaging is already bordering on being too granular. Second, this
D> won't fix one of the major problems I'm trying to fix -- that being
D> programs breaking from week to week only because the kernel headers
D> changed.
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.
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.
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?
>From my perspective, I've been using a kernel that's pretty close to
the latest since I started using linux (about 6-8 months ago), and I
plan to continue to do so. Part of it is demanded by the nature of
the development I'm doing, part of it is a need for the newer
features, and part of it is because I'm interested in checking them
out.
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.
This is my *primary* concern.
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.
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.
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.
All this said, I imagine that the number of packages for which this
would often be a problem is pretty small anyway.
Hopefully I understood the situation enough for this to be
useful/meaningful.
--
Rob
Reply to: