[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