[OE-core] [PATCH 1/1] uninative.bbclass: Fix broken symlink issue

[Mark Hatle]

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).

Signed-off-by: Mark Hatle <mark.hatle at windriver.com>
---
 meta/classes/uninative.bbclass | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index a410647328..670efa9f05 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -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; \
-- 
2.14.2.666.gea220ee