[Cc: familiar-dev as this explains a bit more why there's no current version of bitbake in our tree]
On Sun, 2006-07-09 at 13:58 +0100, Richard Purdie wrote: > > As for the other things you changed, well, we're not using a current > > version of bitbake (I outlined the reasons a while back) > > I realise this is your choice and accept that. It does concern me though > as you're becoming stuck with what amounts to old buggy and unmaintained > software. It's not like the version of bitbake we're using is particularly buggy. It's slow but otherwise works reliably, and there are no issues with dependency handling. > Its a shame we've reached an impasse on the issue as one small > change allows you to use the latest bitbake. I agreed that change isn't > ideal but is it worth the cost? That's not the only problem. Upgrading bitbake to a current version is a major change and requires the necessary amount of testing. From experience with a couple of OpenSlug builds we did with org.oe.dev and bitbake 1.4.x at university a few weeks ago I know that while the standard use cases still work fine, other things go wrong. This simply needs more investigation which in turn requires time I don't have right now. > FWIW, the way OE uses that variable was > wrong and should never have been allowed, it just happened to work. bitbake traditionally didn't even know nor ever look at RDEPENDS. Claiming now that whatever OE did with RDEPENDS was wrong because the current version of bitbake evaluates RDEPENDS and doesn't handle certain things seems rather odd to me. Specifying RDEPENDS depending on the outcome of a build is a vital feature and must be supported. > We > need to find an alternative to what its doing, particularly with the way > bitbake development will head (multithreading). In the meantime, that > "fix" does avoid the problem in a way that is totally hameless and will > not break anything. Well, the RDEPENDS handling code appears to be another step in the wrong direction since it further limits what you can do with OE. Multithreading, btw, doesn't actually require the current RDEPENDS handling, you could just as well flatten the dependency tree by moving DEPENDS to the image .bbs. Also, due to the way the RDEPENDS code currently just appears to munge DEPENDS and RDEPENDS spaces, I'm not convinced it actually improves the quality of the metadata. I mean... there's stuff along the lines of PROVIDES = "$PACKAGES" in OE now. Long story short, the recent improvements in bitbake come at a price that I'm not sure I'm willing to pay. > I'm a little concerned that familiar is drifting away from OE the way it > is. I no longer see commits to familiar and I suspect familar devs don't > see commits to OE. > > As an example, looking at the above patch, I see you've made some > improvements to tslib and this "detect-tsdevice" which I was unaware of > and would have been useful as I also found similar bugs in poky/OE and > fixed them a different way. OE now has udev handling the tsdevice setup. > We should really be trying to share these things. What type of sharing are you thinking of? Both repositories are public, so I can't think of anything that would prevent anyone from merging things back and forth. I am aware of your udev changes btw. I haven't merged them, because detect-tsdevice appears to work fine and touching that type of thing would mean unnecessarily risking non-functional images again. Regards, Rene -- Rene Wagner rw at handhelds dot org 4F33 7FD7 93B3 166B BADA D6F8 71A1 FEA8 58B4 36D0
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Oe mailing list [email protected] https://www.handhelds.org/mailman/listinfo/oe
