uninative.bbclass: Fix broken symlink issue

If two builds are sharing the same DL_DIR, and the uninative file is local
to a layer.  When the first build gets to uninative it creates the link local
to itself, and subsequent users can use the same link.  However if that first
build then is deleted from the disk, the symlink is no longer valid (broken).

We need to update the system to detect this case, and use the model
implemented by the bitbke fetch2 code.  Look for a broken link, remove it,
then try to create the link and ignore an exception if it already exists
(since we just unlinked any bad one).

(From OE-Core rev: bfd9664edad7044b5da53fc33b8d0f6508f00950)

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Mark Hatle
2017-12-07 16:20:04 -05:00
committed by Richard Purdie
parent eec10b92a4
commit 2ff88ae0e0

View File

@@ -63,7 +63,19 @@ python uninative_event_fetchloader() {
fetcher.download()
localpath = fetcher.localpath(srcuri)
if localpath != tarballpath and os.path.exists(localpath) and not os.path.exists(tarballpath):
# Follow the symlink behavior from the bitbake fetch2.
# This will cover the case where an existing symlink is broken
# as well as if there are two processes trying to create it
# at the same time.
if os.path.islink(tarballpath):
# Broken symbolic link
os.unlink(tarballpath)
# Deal with two processes trying to make symlink at once
try:
os.symlink(localpath, tarballpath)
except FileExistsError:
pass
cmd = d.expand("\
mkdir -p ${UNINATIVE_STAGING_DIR}-uninative; \