On Fri, 2006-07-14 at 23:37 +0200, Rene Wagner wrote: > On Sun, 2006-07-09 at 13:58 +0100, Richard Purdie wrote: > > 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.
This is a much better reason than the one you originally gave and one I can agree with. There shouldn't be problems with .dev but if there are, we/I will deal with them if/when identified. > > 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. We have to take a step back and look at the big picture. Having RDEPENDS variables that magically set themselves after a package is built and *error* beforehand is not a behaviour we can support. It is not how the shlibs code works and it not the way standard bitbake variables behave. It happened to work before, doesn't now and should never have been allowed. > Specifying RDEPENDS depending on the outcome of a build is a vital > feature and must be supported. The issue is whether RDEPENDS variables should error when bitbake looks at them. Its my belief they should not as there is interesting information in that variable which bitbake *needs* to look at if we're going to do the inferred DEPENDS code. bitbake don't care whether the version fields are filled in or not and doesn't need to care but it has to be able to read the variable without triggering a bb.fatal(). > Multithreading, btw, doesn't actually require the current RDEPENDS > handling, It doesn't, no. It was something I wanted to clean up before starting that though as the old handling was plain wrong. FWIW, the cleanup in bitbake dependency handling code that implementing multithreading is looking to bring about is actually quite impressive and the code will be a lot more accessible when its done. It will also let me fix a least one known bug that can't easily be addressed in the current codebase (which needs a rewrite). > you could just as well flatten the dependency tree by moving > DEPENDS to the image .bbs. We had fixed DEPENDS and at the time, we all agreed, you included that we should be able to do something better. The DEPENDS >= RDEPENDS madness was just that. Personally, I think the meta data in OE is much cleaner after those changes and the DEPENDS and RDEPENDS variables can now be used as intended without forcing RDEPENDS to have to appear in DEPENDS. > Also, due to the way the RDEPENDS code currently just appears to munge > DEPENDS and RDEPENDS spaces, "munge" is a little strong given you've demonstrated above you only have a superficial knowledge of what's involved. > 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. There should not be and if I'd seen that, I would have done something about it as it doesn't sound right. Can you point me at any specific examples? There is an education issue here as people need to adapt to the changes. I'm sure if I started poking around the Familiar tree I could find equally bad metadata :-(. > Long story short, the recent improvements in bitbake come at a price > that I'm not sure I'm willing to pay. At least "not sure" gives me some hope. I've done my best to try and illustrate why we can't have core variables that error when bitbake tries to read them which is the root of the problem. I'm not sure I can explain it any other way :-(. > > 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. I'm fine with that and wouldn't have expected you to merge it. I'm quite pleased you're aware of the change as it proves communication is open, at least one way. My point is that sadly I'm not aware of changes going into the familiar tree :-(. Some of that is arguably my fault as it is a public tree but that doesn't change the fact I don't see the changes due to the changed workflow and can't easily adapt the way I work to see those changes. The Familiar tree has fixed bugs that were/are in OE and its sad OE hasn't had the benefit of those fixes. I hope that will be rectified in future although I don't know that it will. Regards, Richard _______________________________________________ Oe mailing list [email protected] https://www.handhelds.org/mailman/listinfo/oe
