[OE-core] Coordinating inter-layer dependencies

[Koen Kooi]

Op 1 dec. 2011, om 16:56 heeft Martin Jansa het volgende geschreven:

> On Thu, Dec 01, 2011 at 04:36:40PM +0100, Koen Kooi wrote:
>> 
>> 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.
> 
> But the problem is that we cannot even push newer .bbappend in advance,
> I would be happy to push libdrm-2.4.27.bbappend to master branch if it
> doesn't break my builds which were still on 2.4.26.

I thnk that either

a) becomes a matter of PREFERRED_VERSION of your distro
b) DEFAULT_PREFERENCE = -1 for the update in the grace period.

> Would be nice to be able to push danglings bbappends for stuff which is
> only sitting on ML for review just in case I'll be at daywork or on
> holidays or whatever when it gets applied to ie oe-core and someone just
> hits update button..

Which is where the grace period comes in :)

> I think the problem is not with *big* layers like oe-core and meta-oe
> where is only 1 main maintainer but at least having full time job
> related to maintaining it. But to maintain some hobbyist or community
> layer in general in free time is sometimes pretty demanding just to stay
> compatible with the rest of world (not breaking the rest of world if
> they just want some BSP layer available from it). I wouldn't be
> surprised if meta-smartphone BSP layers get disabled in layerman next
> time I leave for month long holiday...

That's an unfortunate side effect of having a low busfactor. I'll put that in the "shit happens" bin. The proposal won't fix every breakage, but it would make all our lives a lot easier for most upgrades.

Maybe after a while we'll realize that tracking OE-core is too painfull with a full set of slow layers, but I'd like to try this proposal first before giving up[1].

regards,

Koen

[1] Translation: I'm too lazy to add an automated 'lock layer' button to layerman right now 
-------------- 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/7272402f/attachment-0002.sig>