| Summary: | Recipe B with new DEPENDS to A doesn't wait for updated package A | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Ernst Persson <ernstp> | ||||||||
| Component: | bitbake | Assignee: | Richard Purdie <richard.purdie> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | Medium | CC: | poky.bs.watcher, poky.watcher | ||||||||
| Version: | 2.4.5 | ||||||||||
| Target Milestone: | 2.8 | ||||||||||
| Hardware: | x86 | ||||||||||
| OS: | Multiple | ||||||||||
| Whiteboard: | |||||||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||||||
| Verified: | Documentation change: | Don't know | |||||||||
| Attachments: |
|
||||||||||
Hi, Can you confirm this was with 2.4.5? Does the issue reproduce with current master or a supported stable release? Cheers, Richard This is with 2.4.4, the latest 2.4 release afaik. Haven't tried to repro on anything else... Created attachment 4459 [details]
Patch 1
Created attachment 4460 [details]
Patch 2
Can be reproduced on current master. 1) Apply patch 1 2) bitbake foo 3) Apply patch 2 4) bitbake bar fails. However, this sequence does not fail: 1) Apply patch 1 2) bitbake foo 3) Apply patch 2 4) bitbake foo 5) bitbake bar Created attachment 4461 [details]
fail-log.txt
I had a look at this and whilst do_package of foo reruns, do_populate_sysroot does not. This is because do_populate_sysroot has no dependency on the GROUPADD_PARAM* variable.
I think something like:
diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
index 5e600dec849..e5f3ba24f9d 100644
--- a/meta/classes/useradd.bbclass
+++ b/meta/classes/useradd.bbclass
@@ -184,6 +184,7 @@ def update_useradd_after_parse(d):
bb.fatal("%s inherits useradd but doesn't set USERADD_PACKAGES" % d.getVar('FILE', False))
for pkg in useradd_packages.split():
+ d.appendVarFlag("do_populate_sysroot", "vardeps", "USERADD_PARAM_%s GROUPADD_PARAM_%s GROUPMEMS_PARAM_%s" % (pkg, pkg, pkg))
if not d.getVar('USERADD_PARAM_%s' % pkg) and not d.getVar('GROUPADD_PARAM_%s' % pkg) and not d.getVar('GROUPMEMS_PARAM_%s' % pkg):
bb.fatal("%s inherits useradd but doesn't set USERADD_PARAM, GROUPADD_PARAM or GROUPMEMS_PARAM for package %s" % (d.getVar('FILE', False), pkg))
should fix this.
Thanks for the reproduction steps, that helped massively here! Awesome! Wrong bug number in the commit message :-) |
1) Have package A which inherits useradd. 2) Build it to make sure it's in the sstate cache 3) Add GROUPADD_PARAM_${PN} = "foo" to package A 4) In package B add DEPENDS += "A" and "install -g foo some ${D}/some" 5) bitbake B Bitbake will now see that both A and B needs updating and start building both in parallel. B will however get an old version of A in it's sysroot, and the "install -g foo" will fail because the group doesn't exist. If you build A and then B in sequence it won't fail. It looks like updating PV or PR works around this issue.