[oe] [RFC] How to handle external kernel patches in oe the right way?

Rod Whitby rod at whitby.id.au
Tue Sep 4 22:21:09 UTC 2007


Stefan Schmidt wrote:
> Due to my work on OpenEZX (http://www.openezx.org) I'm in touch with
> external kernel patches used in OE to build working kernels for
> different Motorola mobile phones.
> 
> Talking with Koen about the best way to handle this we have some
> slightly different opinions on this. So we like to get some more
> opinions on this before pinning to a strategy.
> 
> Koen like to pull the patches from a known-good rev into oe to have
> them all at one place for less fragile building and tweaking.
> 
> I prefer OE to use our svn server with a fixed SRCREV which gets
> updated once a newer version is known good. I'm not a fan of
> duplicating the patches in OE if some small tweaking patches can also
> handle it.

For the ixp4xx-kernel in OE, I pull patches from a fixed known-good rev
in the nslu2-linux.org kernel patches svn.  The reason is that it makes
it easier to keep the patches in sync for OE, OpenWrt and Debian (which
all use those patches).

> For bleeding edge building and testing we will create a recipe with
> DEFAULT = -1 anyway.
> 
> I'm not totally against Koens approach, just see not much sense, but
> more problems in duplicating the patches in OE. If other people are
> still for it we can of course go that route.

I can see both points of view.  As an upstream kernel patch maintainer,
I like to keep a single respository, and then use that in all the
downstream distributions (OE being just one of them) directly.  As a
distro maintainer, Koen wants to ensure that OE is not affected by
downtime on the upstream server.  Both are valid (but conflicting)
points of view.

Since I'm the ixp4xx-kernel.bb maintainer in OE at the moment, then I
feel that I have the right to choose the way that works for me for that
package :-)  Since I also run the upstream svn server, I can ensure that
it has a better uptime than the OE monotone server and wiki ;-)

-- Rod




More information about the Openembedded-devel mailing list