[Novalug] Kernel Compiles

[James Ewing Cottrell 3rd]

Hmmm, I must be being unclear.

We agree violently...vanilla is not is desired.

I lifted the kernel-#-#.i386.rpm wholesale from the F7 distro and rpm'ed 
-i it right on top of the RHEL 5.2 distro.

They probably had 90% or more of the same patches in common.

Red Hat does a Good Job at selecting patches to the kernel. I just used 
a kernel from "the future".

Think of it as RedHat Sid. :)

JIM

Bryan J Smith wrote:
> Of course patches "take too long" to figure out. But going vanilla
> isn't the answer, and breaks things (sometimes data).  This is
> really a software 101 discussion - features v. integration/regressions.
> 
> --  
> Bryan J Smith - mailto:b.j.smith at ieee.org  
> http://www.linkedin.com/in/bjsmith
> Sent via BlackBerry from T-Mobile  
>     
> 
> -----Original Message-----
> From: James Ewing Cottrell 3rd <JECottrell3 at comcast.net>
> Date: Mon, 19 Apr 2010 15:17:58 
> To: Bryan J. Smith<b.j.smith at ieee.org>
> Cc: novalug<novalug at calypso.tux.org>; Maxwell Spangler<maxlists at maxwellspangler.com>
> Subject: Re: [Novalug] Kernel Compiles
> 
> What "takes too long" is trying to figure out WHICH patches achieve the 
> functionality I need.
> 
> Guess what? The Fedora 7 kernel and lm-sensors dropped right into RHEL 
> 5.2 (or was it 5.1?)
> 
> Porting source code for Icky Hardware Features is not for those with a 
> weak stomach. Or even a strong one.
> 
> Nobody ever said "replace the vanilla kernel". We all know that's what 
> we start with because that is RPM's philosophy...Pristine Sources.
> 
> But like I keep saying...most programs work with most hardware. The line 
> between GNU/Linux is almost perfectly orthogonal in my experience.
> 
> JIM
> 
> Bryan J. Smith wrote:
>> What "takes too long"?  Don't understand.
>>
>> If you want a "vanilla" kernel, just comment out all of the patches in the SRPM's
>> SPEC file.  You'll get a "vanilla" kernel.  If you want to replace the "vanilla"
>> kernel, then replace it in the SPEC file.
>>
>> Of course, doing so will:  
>> - Utterly break the kABI (let alone API)
>> - Cause all sorts of patches to fail, rendering those fixes useless
>>   (and now you must track down if they were addressed in newer releases,
>>    and patch if not)
>> - Render various subsystems useless and/or totally broken
>>   (remember, Enterprise Linux is about all sorts of technical capabilities that
>>    are "afterthoughts" for most users and those foci ;)
>> - Possibly prevent your system from booting with it entirely
>>   (especially if you're using enterprise infrastructure and other init-time capabilities)
>>
>> So, at some point, why not Fedora?  Seriously!  Fedora is not unstable, it just cycles
>> every (X+2)+1 month, so you shouldn't standardize on it more than 1 year at a
>> time.  Fedora is still built with the same, proven process as Red Hat Linux before
>> it (unit-integration-regression), and expands the community options for additional
>> maintainers.
>>
>> Fedora(TM) exists where there is no commercial feasibility for Red Hat(R), or a
>> market Red Hat(R) is not interested in (e.g., content providers) or before Red Hat(R)
>> has turned a newer capability into a commercially feasible solution .  That's all.  It's
>> more than just a distro, it's an entire approach.  It's very reliable, mission-ready and
>> works well.  It keeps up with newer developments very well.
>>
>> So why would you purposely break kABI and introduce countless integration issues
>> (let alone regressions) by continually rebasing the kernel in Enterprise Linux, instead
>> of just using Fedora?  Seriously scratching my head there.  Unless, of course, you
>> believe the non-user comment that Fedora is somehow "unstable," which I haven't
>> heard out of people for years now (and, thank God, is largely removed).
>>
>> You can't get the ultimate in integration testing and regression avoidance by rebasing
>> software regularly.  That's Software Engineering 101.  Has nothing to do with stability.
>>
>>  
>>
>>
>> ----- Original Message ----
>> From: "jecottrell3 at comcast.net" <jecottrell3 at comcast.net>
>> To: Bryan J. Smith <b.j.smith at ieee.org>
>> Cc: novalug <novalug at calypso.tux.org>; Maxwell Spangler <maxlists at maxwellspangler.com>
>> Sent: Tue, April 13, 2010 6:52:44 PM
>> Subject: Re: [Novalug] Kernel Compiles
>>
>> Good Posting.
>>
>> So if I understand you correctly, I should...
>>
>> [1] start with the existing RHEL kernel for the currect distribution
>> [2] go find the appropriate patches to add the functionality I need
>> [3] integrate it into the current SRPM process (patchN+1)
>> [4] build a new kernel
>>
>> You're Absolutely Correct. This is the Right Way to do it.
>>
>> Except that it takes too long. I'd rather
>>
>> [A] Try a kernel from a newer distro
>> [B] See if I can shoehorn it into an existing distribution.
>> [C] Hope that it works
>> [D] Be Lucky
>>
>> I claim that with close relatives in the Fedora/RHEL family, there is a High Chance of Success.
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com 
>> Version: 9.0.801 / Virus Database: 271.1.1/2811 - Release Date: 04/14/10 14:31:00
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com 
>> Version: 9.0.801 / Virus Database: 271.1.1/2820 - Release Date: 04/19/10 02:31:00
>>