Proposal to add build of kernel-backports package to kernel.spec

[John W. Linville]

On Wed, Nov 16, 2011 at 05:22:16PM -0500, Dave Jones wrote:
> On Wed, Nov 16, 2011 at 04:48:07PM -0500, John W. Linville wrote:
>  
>  > Hmmm...I guess there was some misunderstanding between us.  I reckon
>  > that I didn't catch that you were making a distinction between
>  > compat-wireless and my tree that it pulls from.  I thought the
>  > objection was to building a separate package from the kernel spec.
> 
> Earlier in this thread I mentioned wanting to avoid this situation:
> <user> my wireless is broken.
> *files bug*
> <us> install compat-wireless!
> <user> ok, it worked!
> 
> Why don't we just make this code the default, and have it just work.

I want to do just that.  I just wanted to make sure I had the bases
covered before it went live. :-)

>  > FWIW, using the compat-wireless version is a lot less work, since all
>  > the backporting bits should be done already.  And it takes advantage
>  > of the backporting skills of the members of that project, rather
>  > than relying solely on me.  I think it is a better way to proceed,
>  > and one I can actually commit to doing.
> 
> How I see this making most sense :
> 
> f15/f16: what you have in compat-wireless, but apply it as default
> so we ship *those drivers* rather than what was in 3.1
> 
> master: git-wireless.next

The code is the same (minus any required backporting) whether it comes
from compat-wireless or as a big patch from wireless-next.  When it
goes live, I can modify the configs to not build the drivers from the
base kernel, but only build the ones from the wireless tree instead.

>  > > (also, having it be a tarball is a pain wrt review)
>  > 
>  > True, but I'm not sure that a giant patch w/ all the wireless-next
>  > bits in it would be any easier on the eyes...?
> 
> If there's a one-liner that needs fixing up, it means recreating
> and reuploading a new tarball.
> 
> When these changes happen in tarballs, it's entirely opaque when
> it goes to the commits list. We have no idea what changed.

Ah, I see your objection -- that would suck.  But I wouldn't do it
that way.

In fact, with my original efforts I faced exactly this problem.
Fedora had backported vzalloc, and the compat-wireless code had
it too.  I handled that in the %prep section, the same as how the
base kernel is patched (i.e. a %setup for the tarball and a %patch or
ApplyPatch for each patch).

So, any fixes would still be reviewable patches.  The tarball would
only change occasionally.  Reviewing the tarball changes would suck,
but probably not much worse than reviewing an update of a giant patch
from wireless-next.

Does that improve the perspective? :-)

John
-- 
John W. Linville		The water won't run clean until you get
linville at redhat.com			the pigs out of the creek.