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.pur...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
