(Top posting because I'm basically forwarding.) There's another docs idea toward the bottom of this post. Unfortunately, recent changes in the kernel building schema for FC2 and FC3test* have started some flamewars, mostly (methinks) because of misunderstanding. (C'est la vie.) But it does argue for some quick docs work. There is a link below to a write-up that Arjan van de Ven did for FedoraNews.org not too long ago. I'm sticking it in the archives for reference. Again, if no one has a quibble, I'll Bugzilla this. On Sun, 2004-08-22 at 14:45, Bob Arendt wrote: > Arjan van de Ven wrote: > >>If fedora.us accepts the fact that multiple-repos (co)exist, and would > >>be willing to work on interoperability/compatibility I would very much > >>welcome a new kernel module framework outside of Arjan's reach ;) > > > > You know, YOU and 2 or 3 other people are the reason I entirely stopped > > caring about this. No matter what I do you or those others will just > > flame me and personally attack me. So I rather do just nothing and > > ignore the entire thing. > As a kernel source user, module builder, I'd like to speak in *favor* > of the new kernel src.rpm scheme. > > Using mod-versioned kernels, I used to have to rebuild kernel-source > up through the "make dep" stage to get valid kernel headers to compile > against. It was error-prone; If I didn't change the Makefile > EXTRAVERSION, or copy the correct architecture config file to start > with, I got incompatible headers. Building a module for multiple > archs, this was repetitious. OR - I could burn a *lot* of disk space > replicating the kernel source just to build the headers to build > modules against. Yech. > > Now the kernel headers are included with each kernel install! > Fantastic! No more special builds. ASCII headers compress really > well, so there's little inflation in binary-kernel rpm size. And it's > much easier to build & install the 3rd party hardware drivers we use. > Now 3rd party delivered build scripts "just work" since the correct > headers can always be found with the kernel. Vendors have gotten > fewer callbacks regarding installation. It no longer depends on the > last state of the /usr/src/linux* since someone last used the > kernel-source. In fact, it removes the kernel-source requirement > entirely. > > Better yet, the kernel src.rpm now gives me direct visibility into the > patches that RedHat's applied. kernel-source always used to bug me, > since all I got was the post-patched kernel-source without much info > on how it differed from kernel.org's version. If I just "rpm -i", I > get the virgin kernel source tarball in the ./SOURCES directory. With > "rpmbuild -bp " I get the RedHat patched kernel, equivalent to > kernel-source. Better yet, I can look in kernel.spec and see the > patches applied (with comments) one-by-one. Though the src.rpm had > been available, I'd never really looked at it since most of the > literature (well .. web-searches) steered me towards kernel-source. > > Arjan's write-up here: http://fedoranews.org/colin/fnu/issue14.shtml > seemed to cover the history and issues pretty well. It would be good > to get this written up in a HOWTO or some more easily findable docs. > Especially prior to RHEL4, where I'd expect to see some quality docs > on these procedures, delivered as part of RHEL4 documentation. > > Good work Arjan. -- Paul W. Frields, RHCE
