| Summary: | do_packagedata setscene file race | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Richard Purdie <richard.purdie> |
| Component: | core | Assignee: | Ross Burton <ross.burton> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | alexandre.belloni, meta.mr.watcher, meta.watcher, randy.macleod, ross.burton |
| Version: | 3.2 | ||
| Target Milestone: | 3.4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | AB-INT | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Richard Purdie
2020-08-10 10:09:44 UTC
Its interesting that libsm also has version 1.2.3 running at the same time? Likely, something weird going on with the dependencies according to Richard. cp: cannot create hard link ‘/home/pokybuild/yocto-worker/qa-extras2/build/build/tmp/pkgdata/qemux86-64/runtime-rprovides/(=1.2.3)/libxtst’ Note that /runtime-rprovides/ should contain names not versions. However, in my tiny build I currently also have the following unusual directories: (=10.1.0) (=2.31+git0+1094741224) rtld(GNU_HASH) Looks like either quoting issues, or versions appearing in provides where otherwise not expected. $ ls runtime-rprovides/*=* -d 'runtime-rprovides/(=0.16)' 'runtime-rprovides/(=1.2.3)' 'runtime-rprovides/(=2.36.0)' 'runtime-rprovides/(=0.40.0)' 'runtime-rprovides/(=1.2.6)' 'runtime-rprovides/(=2.40.0)' 'runtime-rprovides/(=0.4.5)' 'runtime-rprovides/(=1.3)' 'runtime-rprovides/(=2.4.102)' 'runtime-rprovides/(=0.7.10)' 'runtime-rprovides/(=1.3.0)' 'runtime-rprovides/(=2.4.48)' 'runtime-rprovides/(=0.9.10)' 'runtime-rprovides/(=1.3.4)' 'runtime-rprovides/(=2.64.4)' 'runtime-rprovides/(=1.0.10)' 'runtime-rprovides/(=1.5.2)' 'runtime-rprovides/(=2.6.8)' 'runtime-rprovides/(=10.1.0)' 'runtime-rprovides/(=1.5.4)' 'runtime-rprovides/(=3.24.21)' 'runtime-rprovides/(=1.0.8)' 'runtime-rprovides/(=1.6.37)' 'runtime-rprovides/(=3.3)' 'runtime-rprovides/(=1.0.9)' 'runtime-rprovides/(=1.6.9)' 'runtime-rprovides/(=3.32.3)' 'runtime-rprovides/(=1.1.1g)' 'runtime-rprovides/(=1.7.10)' 'runtime-rprovides/(=3.8.5)' 'runtime-rprovides/(=1.12.20)' 'runtime-rprovides/(=20.1.4)' 'runtime-rprovides/(=4.4.16)' 'runtime-rprovides/(=1.1.3)' 'runtime-rprovides/(=2.0.5)' 'runtime-rprovides/(=5.0.3)' 'runtime-rprovides/(=1.1.4)' 'runtime-rprovides/(=2.10.2)' 'runtime-rprovides/(=5.2.5)' 'runtime-rprovides/(=1.14)' 'runtime-rprovides/(=2.13.1)' 'runtime-rprovides/(=6.2)' 'runtime-rprovides/(=1.1.5)' 'runtime-rprovides/(=2.2.9)' 'runtime-rprovides/(=67.1)' 'runtime-rprovides/(=1.16.0)' 'runtime-rprovides/(=2.31+git0+1094741224)' 'runtime-rprovides/(=8.0)' 'runtime-rprovides/(=1.18.1)' 'runtime-rprovides/(=2.3.3)' 'runtime-rprovides/(=8.44)' 'runtime-rprovides/(=1.2.0)' 'runtime-rprovides/(=2.34.2)' 'runtime-rprovides/(=1.2.11)' 'runtime-rprovides/(=2.35.2)' Looks like the code isn't handling versions at all, and there's just a good old fashioned race over genuinely racing files. The code that is populating those files should be handling the RPROVIDES string containing versions, surely. I just posted a patch to the list to run the RPROVIDES list through explode_deps() so that directories such as (=1.2.3) are no longer created. However the race still exists, if two packages (foo and bar) RPROVIDE the same name (flob) then they'll want to create pkgdata/runtime-rprovides/flob/(foo|bar). If the stars align, foo can be running sstate_clean_manifest (thus deleting flob) whilst bar is in copyhardlinktree, in between the tar (to create the directories) and the cp (to put links into the directories). |