Bug 2235 - Some recipes not 'upgrade' safe
Summary: Some recipes not 'upgrade' safe
Status: RESOLVED DUPLICATE of bug 238
Alias: None
Product: Meta-yocto
Classification: Build System, Metadata & Runtime
Component: meta-yocto (show other bugs)
Version: 1.3
Hardware: x86 Multiple
: Medium normal
Target Milestone: 1.3
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2012-04-03 20:49 UTC by Gary Thomas
Modified: 2012-04-06 16:27 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments
Log of failed build (11.34 KB, application/octet-stream)
2012-04-03 20:49 UTC, Gary Thomas
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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 ***