Bug 2235

Summary: Some recipes not 'upgrade' safe
Product: [Build System, Metadata & Runtime] Meta-yocto Reporter: Gary Thomas <gary>
Component: meta-yoctoAssignee: Richard Purdie <richard.purdie>
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: Medium CC: jessica.zhang, poky.bs.watcher, poky.watcher
Version: 1.3   
Target Milestone: 1.3   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---
Attachments:
Description Flags
Log of failed build none

Description Gary Thomas 2012-04-03 20:49:34 UTC
Created attachment 435 [details]
Log of failed build

It seems that at least some recipes in the Poky tree do not work well when the base repository (${COREBASE}) is upgraded.  Here's how I discovered it, assuming
that ${COREBASE} points to the Poky/Yocto repository, ${BUILD} is some build tree:

* Build using Poky/Yocto revision 7b01671 - I used qemuarm + core-image-sato
  % cd ${COREBASE}
  % git checkout 7b01671
  % . ${COREBASE}/oe-init-build-env ${BUILD}
  % bitbake core-image-sato

* Upgrade $COREBASE to 723c912
  % cd ${COREBASE}
  % git checkout 723c912
  
* Rebuild in the same build tree
  % . ${COREBASE}/oe-init-build-env ${BUILD}
  % bitbake core-image-sato

This will result in multiple failures, at least one of which is shadow-native,
logfile attached.  There seems to be no way to repair this package build, other
than start with a totally fresh ${BUILD}, which of course works fine.

Note: I chose these two revisions as they match points where I had builds that
failed.  I have seen similar issues in the past with other revision points, but
this will give the examiner something solid to look at.
Comment 1 Richard Purdie 2012-04-06 16:27:57 UTC
For reference, this problem was a very unusual situation, not a normal case. The problem was that two packages ended up providing the same sstate files and ended up trampling over each other, even when the overlap was fixed. I think the real solution here is not to support overwriting files and to make that something which can never happen. There is an open bug related to this issue and therefore I'm going to suggest we fix this issue by fixing that one.

*** This bug has been marked as a duplicate of bug 238 ***