[OE-core] Coordinating inter-layer dependencies

Koen Kooi koen at dominion.thruhere.net
Thu Dec 1 15:36:40 UTC 2011


Op 1 dec. 2011, om 14:13 heeft Martin Jansa het volgende geschreven:

> On Thu, Dec 01, 2011 at 01:02:38PM +0000, Richard Purdie wrote:
>> On Thu, 2011-12-01 at 10:59 -0200, Otavio Salvador wrote:
>>> On Thu, Dec 1, 2011 at 10:37, Richard Purdie
>>> <richard.purdie at linuxfoundation.org> wrote:
>>>        On Thu, 2011-12-01 at 13:24 +0100, Martin Jansa wrote:
>>>> A while back I've proposed to make .bbappend without
>>>        corresponding .bb
>>>> only big fat warning, but not fatal to parse. Now you cannot
>>>        even build
>>>> eglibc if there is libdrm bbappend you don't care at all
>>>        about..
>>> 
>>> 
>>>        You can do this by setting:
>>> 
>>>        BB_DANGLINGAPPENDS_WARNONLY
> 
> Good to know, thanks.
> 
>>> This is even worse; you end up with a package without the changes done
>>> on the bbappend and as most bbappend files do not change PR, adding it
>>> later won't force a package update.
>> 
>> Which is why its off by default. My point is you can do with Martin is
>> suggesting, its just not without its drawbacks.
> 
> I think the main advantage of this is that you're allowed to build stuff
> which doesn't use those dangling appends. Ie start build of eglibc if
> you know that nothing is bbappending to eglibc and to its dependency
> tree. And when .bbaappends are fixed you can disable
> BB_DANGLINGAPPENDS_WARNONLY and build the rest.
> 
> But waiting for _all_ recipes in _all_ layers to get their .bbappends
> right can sometimes a bit long..

Which is why I sent this proposal, to give slow layers like meta-intel time to fix their stuff without breaking everyones build for 2 days till RP gets fed up and fixes it himself.
I don't have the time to maintain forks of every layer like you do with SHR and frankly speaking, it shouldn't be needed. I understand that things like review cycles take some time which is why the proposal tries to workaround the delays in layers in OE-core itself instead of angrily demanding maintainers to act quicker.

regards,

Koen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20111201/b8ac7b37/attachment-0002.sig>


More information about the Openembedded-core mailing list