-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Sokolovsky schreef:
> -K_MAJOR = "2" > -K_MINOR = "6" > -K_MICRO = "15" > -HHV = "0" > +K_MAJOR ?= "2" > +K_MINOR ?= "6" > +K_MICRO ?= "15" > +HHV ?= "0" > > Of course, ideally it should be given just CVS date and be able to > infer corresponding kernel version from the checkout, but I'm not sure > it can be done with OE, as there's going to be circular dependency - > it must provide PV to be selected for specific build, and cannot (and > of course shouldn't) do any actions (like checkout) unless it is > selected. A recipe with a floating cvs is is supposed to be valid against the scm repo at that moment (give or take a day, thanks to timezones), so the version should match what it has in cvs now, and you'll have no problem developing. However... ... if you lock down a cvsdate (for whatever reason) this is only valid if you keep the file 'stale'. By keeping the file 'stale' you prevent people from working against latest cvs and run into the versioning and therefore dependency problems you have. Basically you have to proper options to solve that: 1) remove the SRCDATE lock for the kernel, or slide it forward, while updating the recipe to match 'todays' cvs 2) add a snapshot recipe that build for a fixed that (e.g. when the patches went in) This problem illustrates why I don't like locking down SRCDATEs in config files; it may work, but was never intended to. I had a discussion with Richard about SRCDATE, time-limited patches and reproducability on #oe this afternoon. We still disagree, but we made a compromize and are going to work from there :) With the new bitbake, files are cheap so you can split out the common parts of the kernel recipe into a .inc and make your own snapshot. I still think it's bad form to influence package versions from a MACHINE.conf and consider that, and the cause a bug. This also illustrates why it is usefull to have a development branch (aptly named .dev in OE) and a release branch, so you can cater the bleeding edge people and have proper, stable release management at the same time. I hope this clears up why I called the bugs bugs and why I won't apply that patch to .dev. I'd also like to mention that problems like this (modules missing deps) are usually identified and solved within minutes if you mention it on #oe or a bit slower if you mail the mailinglist. It *really* pays off to touch base with the OpenEmbedded project :) regards, Koen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEsVidMkyGM64RGpERAvIqAJwLOSa2Q/MFauQ1xUeH5be3uHXeCQCdG5tG UBKw3A7/9kUaN7Gasde41Rc= =179z -----END PGP SIGNATURE----- _______________________________________________ Oe mailing list [email protected] https://www.handhelds.org/mailman/listinfo/oe
