Re: Kernel Recompile
Manoj Srivastava <firstname.lastname@example.org> wrote:
> Raul> I don't care if people actually use the code in the package
> Raul> to build kernel images or not. However, I feel that what the
> Raul> code does should be documented, so that those who feel the
> Raul> urge to do it manually can be referred to the documentation.
> Raul> Unfortunately, with the current state of affairs, such folk
> Raul> have a valid objection.
> What valid objection? What, pray, does the kernel-package do which
> is special (apart from not making very many mistakes any more)?
> What should be documented? The developers corner describes pretty
> well already what it takes to create a Debian package. The kernel
> documentation (apart from the /usr/include symlinks) describes how to
> compile a kernel. /usr/doc/kernel-* (various kernel-* [ackages now)
> document how to use make-kpkg.
Manoj, you're too touchy. I don't think there's even a vague chance
that what I'm talking about can be properly addressed by changing
I've been presuming that kernel-package is required if we want to
guarantee that loadable modules work. Some packages provide loadable
modules, some provide loadable module support. kernel-package doesn't
actually guarantee that any config options are set any specific way,
but it provides solid support for keeping modules distinct (much better
than what you get from "make modules-install" using the distributed
makefile... which perhaps implies that something like this support
should get folded back into the upstream sources... but that gets rather
interesting if you try to factor out dpkg).
If packages which require something specific from the kernel
(CONFIG_MODVERSIONS, for example) don't document their requirements then
that is the fault of these packages.
I've seen some people take the tack that their packages should only be
used with pre-built debian-supplied kernels. Implying, presumably, that
people who need something else from the kernel (ip masquerading comes
to mind) are just out of luck. I don't think this is the right approach.
Which leads me back to: packages which require special kernel features,
must document those requirements. This means every package which gets
involved in loadable modules -- and every package which provides loadable
modules should mention kernel-package (and make-kpkg), I believe, as
well as what is known about kernel option requirements.
Finally, because we can't make the requirement that some people have
to build their own kernels go away, I think that packages which provide
modules should also provide a clean way of building new modules-package
instances. At the moment, that means building a source .deb and muttering
under one's breath about how we need a proper source packaging system.
Er.. speaking of which, in addition to the "Prospective Packages" page,
we probably ought to have a "We wish someone would develop this" page,
and the source packaging system requirements ought to be accessible
from that page.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org