[EMAIL PROTECTED] (Dale Scheetz) wrote on 06.01.98 in <[EMAIL PROTECTED]>:
> 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.
Don't use the kernel-source package, then. I usually don't.
Raw kernel source plus kernel-package is what I use most.
> 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)
Well, that's more or less what I do, except I use raw kernels usually.
Ftp the kernel from ftp.kernel.org, unpack somewhere, and then
make menuconfig
make-kpkg --revision kai.17 kernel-image # from kernel-package
dpkg -i ../kernel-image_2.0.33-kai.17_i386.deb
That's *all* there is to it.
And it works. Reliably.
Note that I mentioned kernel-package above, not some kernel-source
package. If you've never used make-kpkg, then you've definitely missed out
on something as important as the menu package!
> > > > 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.
Oh yes? I don't think so.
> > 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.
Obviously, I think the _explanation_ _is_ adequate. That doesn't mean you
have to agree it's the right solution, though I do wonder why you haven't
said so when this was originally discussed.
> > 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)
Well, I do agree that the user side of this seems to be suboptimal right
now. On the other hand, there's also the problem with packages made from
multiple sources.
Personally, I don't like either the old or the new solution. And I don't
have a third one up my sleeve, either.
The only thing that seems clear is that the end effect - specific kernel
headers - is what we need.
MfG Kai
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
