Re: Coordinating inter-layer dependencies

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3228 bytes --]

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@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.

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..

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...

Just my 2c

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]