2010/3/24 Richard Purdie <[email protected]>: > On Wed, 2010-03-24 at 21:17 +0100, Frans Meulenbroeks wrote: >> If a dep is rebuild there is a reason for it (bug fix, packaging >> changed, changes in exported files etc etc). >> This might impact the using recipe. >> If baking a file does not result in a rebuild when a dependency is >> changed, probably a warning should be given. >> >> Encoding the library ABI is only part of the job. You'd also have to >> take the .h files a package exports into account as constants in it >> could be changed. >> And even the using package could change its behaviour (e.g. because >> configure runs differently). >> Note also that if we abandon PR we do not really have an easy >> mechanism to force recompilation of a package (if a depenency changed >> and we want to force a rebuild). > > Its worth noting you can enable this now with BB_STAMP_POLICY. I see > something similar being the likely outcome with checksums. Some people > will want the full dependency tree, some people won't. We can support > both just as we do now.
Supporting both is great. The reason I brought this up is that for application of OE in products, reproducability is important. I've seen too often (also outside OE) that two engineers take the same source yet still get different results, and that bugs at a customer site cannot be reproduced in the lab (and yes, I do know there are other ways to tackle this problem) The thing I would like to avoid is that different people create packages/images that look like being the same (e.g. name/ID) yet have different content. Or in other words: the problem one could face and that I want to avoid is that if A depends on B and A is build and works, but afterwards B is changed and a newly compiled A would have the same name/version but might behave differently than the old one (e.g. because B changed something in a .h file). That could also lead to situations where a local compiled file behaves differently than the same one you'd get from a feed. IMHO less desirable. Frans _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
