[oe] [RFC] Handling Patch Series in OE

[Richard Purdie]

On Fri, 2007-10-26 at 12:09 +0100, Graeme Gregory wrote:
> OM developers are making use of patches stored with a series file
> (quilt style) and have a special pre patch function to apply these
> patches.
> 
> This interferes with OE's current file://patch.patch;patch=1
> application. Namely all patches applied in this way are forgotten from
> patches/ directory when the first OE patch is applied.
> 
> I would like to add a new peice of handling to patch.bbclass that
> handles a patchseries=1 type argument when passed with a URI which
> points to a directory of patches+series file.
> 
> This new handling should play nice with OE's current system to avoid
> information on patches being "lost"
> 
> I am making the assumption that in the case of things like this.
> 
> SRC_URI = "http://blah.tag.gz file://unfsck.patch;patch=1
> http://series.tar.gz;patchseries=1 file://unfsck2.patch;patch=2"
> 
> Then the series should be applied after the first patch and before the
> second. To avoid people getting suprised.
> 
> Any comments before I start to learn python?

No objections to the principle, just some comments about the exact
syntax and how we might want to structure this. A nice game you can play
with SRC_URIs is:

FILESDIR = "${WORKDIR}"

SRC_URI = "http://some.site/some.tarball.of.patches.tar.gz \
           file://patch1;patch=1 \
           file://patch2;patch=1"

Where patch1 and patch2 will get unpacked from the archive and then we
can apply them. This syntax is often quite useful and it would be nice
to extend this to have support for:


SRC_URI = "http://some.site/some.tarball.of.patches.tar.gz \
           file://patch1;patch=1 \
           file://custom_series;patchseries=1 \
           file://patch2;patch=1"

where custom_series is a file from some.tarball.of.patches.tar.gz. 

Yes this means two lines in SRC_URI rather than one but that could be
considered an advantage since the name "series" isn't hardcoded. I
suspect when you get into the code this will actually be simpler to
write too ;-).

Cheers,

Richard