Bug 8788 - Changing RREPLACES does not invalidate sstate signature
Summary: Changing RREPLACES does not invalidate sstate signature
Status: VERIFIED DUPLICATE of bug 7754
Alias: None
Product: BitBake
Classification: Build System, Metadata & Runtime
Component: bitbake (show other bugs)
Version: 1.7.4
Hardware: x86 x86_64
: Undecided normal
Target Milestone: ---
Assignee: Richard Purdie
QA Contact: Bogdan Alexandru Voiculescu
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2015-12-10 18:53 UTC by Bevenson
Modified: 2016-01-22 08:02 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bevenson 2015-12-10 18:53:37 UTC
After adding a RREPLACES variable for a recipe, I noticed that bitbake did not rebuild the package.  I tried calling bitbake -c clean and bitbake -c cleansstate before building, and each time the built package did not contain the "Replaces:" line in the Debian control file (I'm using opkg for a package manager).  I then made other changes to the RREPLACES variable and checked the result of "bitbake -c none package" before and after.  The sstate signatures for the package never changed.  I then modified the "inherit" declaration in the recipe. Then the package was fully rebuilt and I could see the "Replaces:" line in the ipk's control file.

Modifying RREPLACES is not changing the sstate signatures for a package. I am on dizzy-1.7.3, so it may be worth testing with a more recent version to see if this has been fixed by some other change.
Comment 1 Bevenson 2015-12-10 20:04:02 UTC
After some digging around in the classes, I found out that PACKAGEVARS in package.bbclass is missing RREPLACES.  This has been fixed in master with commit ace08a2923117c9fb1f3d232372c433b4bab82d9.  I cherry-picked the commit and verified it fixed my problem.  Closing and marking as a duplicate of #7754.

*** This bug has been marked as a duplicate of bug 7754 ***
Comment 2 Bogdan Alexandru Voiculescu 2016-01-22 08:02:14 UTC
Verified on 8c8c4ede3ff5ac8ca739020d9efed91159acccc1