]> code.ossystems Code Review - openembedded-core.git/commit
sstate: Handle manifest 'corruption' issue
authorRichard Purdie <richard.purdie@linuxfoundation.org>
Fri, 14 May 2021 17:06:56 +0000 (18:06 +0100)
committerRichard Purdie <richard.purdie@linuxfoundation.org>
Sun, 16 May 2021 07:29:56 +0000 (08:29 +0100)
commit63da9a4f889c5b0e41bc8ec08abe0acea1546479
tree1ff8b1ace1b919f0e656d69ccf54cdbf4767ee55
parenta366a457bf0c990df4bb97cfc5477dbc75eaff65
sstate: Handle manifest 'corruption' issue

Under certain build patterns, warnings about missing manifests can appear. These
are real issues where the manifest was removed and shouldn't have been.

Martin Jansa was able to find a reproducer of:

MACHINE=qemux86 bitbake zlib-native
echo 'PR = "r1"' >> meta/recipes-core/zlib/zlib_1.2.11.bb
MACHINE=qemux86-64 bitbake zlib-native
MACHINE=qemux86 bitbake zlib-native
<the zlib-native manifest is now removed along with the sysroot-components contents>

The code maintains a per machine list of stamps but a per PACAGE_ARCH list of
stamp/manifest/workdir mappings. The latter is only appended to for speed with
the assumption that once stamps are gone, the code wouldn't trigger.

The code only ever appends to the mapping list (for speed/efficency under lock)
meaning that multiple entries can result where the stamp/workdir differs due to
version changes but the manifest remains the same.

By switching MACHINE part way through the build, the older stamp is referenced
and the manifest is incorrectly removed as it matches an now obsolete entry in
the mapping file.

There are two possible fixes, one is to rewrite the mapping file every time
which means adding regexs, iterating and generally complicating that code. The
second option is to only use the last mapping entry in the file for a given
manifest and ignore any earlier ones. This patch implments the latter.

Also drop the stale entries if we are rewriting it.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta/classes/sstate.bbclass