[oe] FILE_PR and my requirements Re: Some open issues

[Phil Blundell]

On Sat, 2008-10-18 at 15:37 +0200, Holger Freyther wrote:
> On Saturday 18 October 2008 15:20:05 Holger Freyther wrote:
> > On Saturday 18 October 2008 14:32:37 Holger Freyther wrote:
> >
> > More in depth:
> - We need to make sure that people do not introduce PR but use FILE_PR
> 
> Oops I missed my requirements:
> 	- Easy to understand what is going on
> 	- Package name and Workdir matching with each other
> 	- Full rebuild on DISTRO_PR bump
> 	- Not reusing the same build directory

These seem like fine requirements.  The additional one from me, which I
try to apply to more or less any change in OE, is that any change to the
grammar of .bb files should be both forwards and (to the greatest extent
possible) backwards compatible.  That is, unless there are overriding
reasons why it is impossible, two use cases should both be supported:

(a) backporting cherry-picked recipes from the .dev tree to the stable
branch; and

(b) merging recipes from other, parallel development trees that might be
using slightly older standards or processes.

> And here two patches. The amount of changes is a lot smaller. The downside is 
> it is not as easy to understand as changin PR to FILE_PR (think of the people 
> merging OE into their private trees that know little about the classes...). 
> Anyway this is something we can talk about..

Right, this seems like a good solution.  I'm not sure that it really is
any harder to understand than the FILE_PR thing, and to be honest the
internals of the packaging classes are already cryptic enough that I
doubt many people make any attempt to comprehend them in detail.  The
relationship between PR and PKG_PR is clearly shown in bitbake.conf,
rather than buried in some obscure piece of python, so there should be
no difficulty in understanding for anybody who looks at it.

Requiring a new bitbake version is obviously a bit of a shame but there
is plenty of precedent for that, and the bitbake change looks like it
should be backwards compatible with no problem.

I haven't actually tested the patches so I can't speak for their correct
functionality.  But the general approach seems like a good one to me.

p.