Bug 13262 - Recipe B with new DEPENDS to A doesn't wait for updated package A
Summary: Recipe B with new DEPENDS to A doesn't wait for updated package A
Status: RESOLVED FIXED
Alias: None
Product: BitBake
Classification: Build System, Metadata & Runtime
Component: bitbake (show other bugs)
Version: 2.4.5
Hardware: x86 Multiple
: Medium major
Target Milestone: 2.8
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2019-04-03 11:44 UTC by Ernst Persson
Modified: 2019-06-03 08:32 UTC (History)
2 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know

Attachments
Patch 1 (731 bytes, patch)
2019-04-05 10:18 UTC, Ernst Persson 		no flags Details | Diff
Patch 2 (1.15 KB, patch)
2019-04-05 10:18 UTC, Ernst Persson 		no flags Details | Diff
fail-log.txt (5.47 KB, text/plain)
2019-04-05 10:22 UTC, Ernst Persson 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ernst Persson 2019-04-03 11:44:24 UTC 
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.
Comment 1 Richard Purdie 2019-04-04 14:57:11 UTC 
Hi,

Can you confirm this was with 2.4.5? Does the issue reproduce with current master or a supported stable release?

Cheers,

Richard
Comment 2 Ernst Persson 2019-04-04 15:00:19 UTC 
This is with 2.4.4, the latest 2.4 release afaik.
Haven't tried to repro on anything else...
Comment 3 Ernst Persson 2019-04-05 10:18:32 UTC 
Created attachment 4459 [details]
Patch 1
Comment 4 Ernst Persson 2019-04-05 10:18:52 UTC 
Created attachment 4460 [details]
Patch 2
Comment 5 Ernst Persson 2019-04-05 10:21:01 UTC 
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
Comment 6 Ernst Persson 2019-04-05 10:22:30 UTC 
Created attachment 4461 [details]
fail-log.txt
Comment 7 Richard Purdie 2019-05-31 16:41:55 UTC 
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.
Comment 8 Richard Purdie 2019-05-31 16:51:19 UTC 
Thanks for the reproduction steps, that helped massively here!
Comment 10 Ernst Persson 2019-06-03 08:32:52 UTC 
Awesome! Wrong bug number in the commit message :-)