Stock kernels

[Mike A. Harris]

On Tue, 19 Aug 2003, Jef Spaleta wrote:

>Date: Tue, 19 Aug 2003 08:17:46 -0400
>From: Jef Spaleta <jspaleta at princeton.edu>
>To: rhl-beta-list at redhat.com
>Content-Type: multipart/signed; micalg=pgp-sha1;
>    protocol="application/pgp-signature"; boundary="=-WZ/fPCaMjSBIx+rDELEJ"
>List-Id: For testers of Red Hat Linux beta releases
>    <rhl-beta-list.redhat.com>
>Subject: Re: Stock kernels
>
>Maynard Kuona wrote:
>> Like recently,the kernel.org kernels will not build because of
>> how Redhat split rpm into rpm and rpmbuild
>http://www.rpm.org/hintskinks/rpmbuild/
>
>Recently....that url would suggest that the actual functionality split
>was a while ago.  I think the backwards compatibility mode for rpm hung
>around too long.

rpm and rpmbuild have been separate binaries since Red Hat Linux
7.0 or 7.1 roughly.  It is nothing new of course, and it does not
stop or prevent anyone from using rpm for installation and
package maintenance nor prevent anyone from doing development
either.  It might require someone to read manpages and modify the
habits they're used to, or make popt aliases to get the old
behaviour though.  Personally, I still type rpm when I mean
rpmbuild occasionally, and get the rpm error about unknown
commandline options, then realize my error of habit from days 
gone by, and correct it and move on.

What's changed is changed, and what is done is done.  Popt 
aliases can be set up by diehard oldschoolers if they wish.  
Nonetheless, rpm's functionality is no less of what it was 
before.


>>So if you could provide stock
>>kernels, unsupported though, even for download, it would really be
>>appreciated. The thing is that if they build at Redhat, then there should be
>>less trouble building in the users' hands.
>
>What you are actually asking for...is you want Red Hat to take the most
>recent stock source and test it just enough to make sure that end-user
>can "easily" roll their own kernel. That just isn't going to happen
>inside the distro.

Indeed, definitely not in ready-to-install or ready-to-recompile
rpm format of stock source.  We very likely will never ship an
unpatched stock Linux kernel with zero patches applied to it in
rpm format.  We provide the kernel pristine source and others are
free to package the kernel in src.rpm or binary rpm format from
that source if they desire to compile the kernel in rpm format
from unpatched sources however.  The amount of work to do that 
and then to support it (yes, you ship it, you support it, you get 
the bug reports, and emails, and complaints) is just not viable.

This is very much something that fits into the realm of 
non-general-purpose special interest customization.


>What you get is the stock source code and the spec file for the
>kernels red hat does provide...but thats seldom going to be the
>"newest" kernel...especially if you like running development
>kernels
>Now, developers being developers, you might likely see an individual
>developer offering up kernel rpms for testing newer kernel
>releases...and the associated src.rpm will have the unpatched source.
>But as part of the distro...I highly doubt yer not going to see a second
>set of kernel sources...even if its just for download.
>
>And I'm really not sure of the value of the Red Hat developers making it
>"end-user easy" to build a custom kernel. If you are building yer own
>custom kernel from stock...you should KNOW how to apply patches and KNOW
>how to build your own spec file from provided examples.

Indeed.


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat