Re: What's Debian's /usr/src policy
On 6 Jan 1998, Kai Henningsen wrote:
> dwarf@polaris.net (Dale Scheetz) wrote on 05.01.98 in <[🔎] Pine.LNX.3.96.980105173634.10350H-100000@dwarf.polaris.net>:
>
> > 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: dwarf@polaris.net 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
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: