Re: PW#5-16: Use of /usr/src
Manoj (SuperCite undone):
[ Ian: ]
> > The package that the libc depends on (libc-kernelheaders perhaps)
> > should be a plain .deb file which installs in
> > /usr/include/{asm,...}. The libc should specify the version
> > number via a dependency, rather than by changing the package
> > name, because there is no need or desire to have several sets of
> > kernel headers all available in /usr/include.
>
> There has been a long discussion on this topic. I fail to see
> the advantage of creating a special purpose package just for libc
> purposes.
Err, but you are also advocating creating or maintaining a special
purpose package just for libc purposes. Your statement is as much of
an attack on the status quo as on my proposal.
> I have been informed there is sufficinet interest in a
> kernel-headers package by people tinkering with modules to warrant
> its inclusion in the distribution.
I wasn't suggesting abolishing the package which these people use. I
was suggesting changing its internal structure and its name.
> If kernel headers are to be included anyway (and there are
> really a large number of people who have informed me that they use
> the packages), then it reduces the bureaucratic interaction between
> the libc maintainers and the kernel package maintainers.
>
> For example, when the kernel-* package maintainers release
> 2.0.34, the libc6 maintainer can just upgrade libc6-dev, and point to
> the kernel-headers-2.0.34. No special packages, no prior
> communication between maintainer, no extra synchronization between
> kernel-* maintainers and libc6-dev maintainers on every supported
> architecture required.
This is still true if instead of kernel-headers-2.0.34 (2.0.34-1)
installing in /usr/src we have kernel-headers (2.0.34-1) installing in
/usr/include.
Ian.
--
E-mail the word "unsubscribe" to debian-policy-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@lists.debian.org
Reply to: