More docs ideas?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(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



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Red Hat 9]     [Yosemite News]     [KDE Users]

  Powered by Linux