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

[Richard Purdie]

On Sat, 2008-10-18 at 15:35 +0100, Phil Blundell wrote:
> 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.

I talked with Holger on irc about this. The need is primarily to have a
way of regenerating a full set of packages after some package abi
change. I raised the idea of using DISTRO_PR in a somewhat similar way
to SANITY_ABI where if it changes the user is warned about it and then
can handle as they see fit. DISTRO_PR is appended to the PR values at
package generation time if set. For autobuilders this wouldn't be good
so for those cases I'm suggesting they incorporate DISTRO_PR into the
TMPDIR value their autobuilder uses.

Yes, this kind of change may break some scripts out there. That is
unfortunate but we should use this opportunity to improve the scripts to
use commands like "bitbake -e | grep ^DEPLOY_DIR_IMAGES" and similar to
find things rather than making assumptions about path layout.

The advantages to this approach are that we don't need changes to
bitbake, we don't break the file format, we don't change the file layout
and we leave options open for other requirements that may come along in
the future.

Holger started a patch implementing this which I've added some code
which is shared as:

http://git.openembedded.net/?p=openembedded.git;a=shortlog;h=refs/heads/shared/file-pr-revert

I also took the opportunity to split the ABI variables into a separate
clearly identifiable conf file like Poky.

Cheers,

Richard