[OE-core] Coordinating inter-layer dependencies

McClintock Matthew-B29882 B29882 at freescale.com
Thu Dec 1 19:55:38 UTC 2011


On Thu, Dec 1, 2011 at 5:23 AM, Koen Kooi <koen at dominion.thruhere.net> wrote:
> Hi,
>
> During the past month there have been a number of updates to OE-core recipes that triggered parsing errors due to bbappend in other layers. A small seleciton:
>
> * netbase
> * libdrm
> * xserver-xorg
> * clutter
>
> My view is that layer maintainers need to keep an eye on potential breakage and have updates ready when patches land into OE-core. Looking back I can see that while the situation is improving a bit, it's still not working. The problem with slow updates to layers is that (with my angstrom hat on) users (and with my TI hat on) customers and coworkers can't do builds without rm'ing the bbappends or disabling the layer.
>
> This is bad for a number of reasons:
>
> 1) It creates unmanaged local diffs
> 2) it can cause PR to fluctuate back and forth if you rm is a bit overzealous or if you disable the complete layer.
>
> My proposal is that OE-core recipe upgrades with known bbappends look like this:
>
> 1) add new version with a warning about bbappends
> 2) wait a N days (2 < N < 7)
> 3) delete old version
>
> To avoid stressing out RP and Sau! I would strongly urge layer maintainers to respond to recipe update patches with "I have a bbappend, but my review process needs time, please use the above proposal" if you need time to test and update  your bbappends.
>
> We're all human in the end and timezone differences aren't always helping with these kinds of problems, so let's work together to minimize parsing breakage.
>
> Related to that: Please include information on how to send patches upstream in your layer/repo README. The meta-intel/emenlow lacks that and the top level README doesn't mention that there are sublevel READMEs.

Why don't we make a version of bbappend that applies to all packages
with the same name? This would fix the constant changing
netbase_vXYZ.bbappend issue.

-M




More information about the Openembedded-core mailing list