Re: What's Debian's /usr/src policy
Hi,
>>"Joel" == Joel Klecker <jk@espy.org> writes:
Joel> -----BEGIN PGP SIGNED MESSAGE-----
Joel> Regarding "Re: What's Debian's /usr/src policy" of 4:34 PM -0600
Joel> 1/16/98, Manoj Srivastava wrote:
>> So, a dependency was cerated on kernel headers rather than create
>> kernel header sized architecture dependent diffs. (Still makes
>> sense to me ;-)
Joel> Yes, I think it makes sense too (though I have been working with
Joel> glibc quite a bit lately, and its docs don't seem to consider it
Joel> a big deal to have /usr/include/{asm,linux} be symlinks to
Joel> /usr/src/linux/include/{asm-$ARCH,linux}, where /usr/src/linux
Joel> is whatever kernel version happens to occupy that directory).
Joel> The current problem is that libc6-dev depends on
Joel> 'kernel-headers-2.0.32' or 'kernel-source-2.0.32'.
This is not really a problem, it is a solution ;-)
Joel> I suggest it depend on 'kernel-headers' instead, and then each
Joel> architecture would provide its own arch-dependant
Joel> 'kernel-headers' package (which could be a virtual package), it
Joel> would install into /usr/include{asm,linux}, thus leaving room
Joel> for 'kernel-source' in /usr/src.
You are missing the point. That would take us to the
deprecated old libc5 system that we escaped a long time ago. The
point is, libc development packages should include a static, stable,
tested, known good kernel headers to insulate developers from the
vagaries of unstable kernel headers.
Depending on precisely 'kernel-headers-2.0.32' gives us
that. Please read my posting earlier why libc dev packages
should not depend on any old kernel include files.
Joel> Actually, on a bo system, what is kernel-headers for? It is for
Joel> people who want to compile programs that need the kernel headers
Joel> for the current kernel, but don't want to compile kernels or
Joel> don't have the disk space for the full kernel sources, correct?
That would be less than 10 packages of the 1600 or so we now
have. Most packages do not need to be that chummy with kertnel
internal structures (think; if they really needed a particular kernel
headers, then the binary would need to be recompiled with every
kernel change on the machine)
Joel> m68k and i386, and alpha(?) are currently using the same libc6
Joel> sources, correct? And I assume the 2.0.32 kernel headers are
Joel> only useful for i386, and possibly alpha, therefore, the
Joel> dependency on 'kernel-headers-2.0.32' is only correct for at
Joel> most, two architectures.
This happens not to be the case. Or at least, this invariant
is not guaranteed for any future releses. Kernel headers may not be
the same for any two given architectures. And our solution is
prepared for that.
Joel> powerpc, and sparc both use glibc 2.1, but I expect that the
Joel> others will move in that direction eventually, once glibc 2.1
Joel> goes final.
That is indeed the desired goal, but it may take longer than
one suspects. When it happens, libc7 shall no longer depend on
kernel-headers.
manoj
--
"There is no reason anyone would want a computer in their home." Ken
Olson, president, chairman and founder of Digital Equipment
Corp.,1977
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: