On 6 Jan 1998, Kai Henningsen wrote: > [EMAIL PROTECTED] (Dale Scheetz) wrote on 05.01.98 in <[EMAIL PROTECTED]>: > > > On Mon, 5 Jan 1998, Ian Jackson wrote: > > > > > I think that /usr/src should the be domain of the local admin. > > > > > > I don't think kernel-{header,source}-x.xx.deb should exist, really, > > > because I don't think source code should be distributed as .deb files > > > anyway. So I'm not unhappy about making a policy decision that leaves > > > kernel-{header,source} with nowhere good to go. > > > > I never understood why the kernel source was made into a .deb package. It > > doesn't make sense to me. I also don't see any point in "managing" a > > binary package of the kernel either. The system doesn't gain anything by > > having dpkg know which kernel binaries are installed either. The binary > > thus installed still needs to be configured for lilo or loadlin or grub, > > so what's the point? > > Well, handling kernels with kernel-package is _a_lot_ easier than doing it > by hand. I've done both, and I don't want to go back, ever.
I'm sorry, but my experience has been very different. I too have tried both. Maybe my timing has been poor, but both times I tried there was a mismatch between the kernel-package package and the kernel-source package and after much futsing around resulted in failure. Kernel source should be provided the way we provide source for all other packages. You should be able to unpack it with dpkg-source -x and run dpkg-buildpackage and build a kernel to your spec and construct a .deb package from that result. (Note, I have no real problem with a kernel-binary package, although personally I would have no use for it, I can understand others point of view in wishing to "manage" their kernels with dpkg) > > > > Why does libc6 depend on kernel-header ? > > > > I don't know either, but it is on the top of my list of things I need to > > understand as the new maintainer. It was my understanding that the way we > > deal with kernel headers was supposed to free the c library from the > > headers. I don't know that anything has changed in that reguard. I'll let > > you know what I find asap. > > I think our main problem here is that people (including both you and Ian) > don't keep on top of debian-private and debian-devel. I can't speak for Ian here, but I am a constant reader and participant on both these lists. Your implication is both unfair and has nothing to do with the technical discussion. > I can't count the > times this has been explained already, and I get very, very tired of it. > I am sorry for your exaustion. I am capable of counting, but what is the point. The reason this keeps coming up is that, so far, all explanations have been inadequate. > libc6 depends on a specific version of kernel-headers to avoid including > what is in that package as a diff. Nothing more, nothing less. > This exaplanation is inadequate as well. While shrinking the size of a diff file helps the developer who pays by the byte/minute for access, it creates a problem for the user which is not necessary. Forcing the coupling of two packages via depends when the two packages are only used together makes installation and upgrades one step more complex than is necessary in a way that adds to package bloat when it isn't necessary. (BTW it's libc6-dev that is coupled to kenrel-headers) Still unconvinced, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide" _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .