Bug 14205

Summary: [Poky] Poky's sanity.bbclass and path.py assume tar is gtar
Product: [Build System, Metadata & Runtime] Other YP Layers Reporter: Bernhard Rosenkränzer <bero>
Component: layersAssignee: Simone Weiß <simone.p.weiss>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: poky.bs.watcher, poky.watcher, randy.macleod, richard.purdie, simone.p.weiss
Version: unspecified   
Target Milestone: Future   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Bernhard Rosenkränzer 2021-01-27 17:55:25 UTC 
Poky makes various assumptions about "tar" being GNU tar.

There is no way to override the location of tar (e.g. TAR=gtar) for distros that use a different default "tar".


I've had successful builds with libarchive tar by skipping the check in sanity.bbclass, replacing
cmd = "tar --xattrs --xattrs-include='*' -cf - -S -C %s -p . | tar --xattrs --xattrs-include='*' -xf - -C %s" % (src, dst)
in poky/meta/lib/oe/path.py with
cmd = "tar c --xattrs -f - -S -C %s -p . | tar x --xattrs -f - -C %s" % (src, dst)
and replacing (in the same file)
cmd = "cd %s; find . -type d -print | tar --xattrs --xattrs-include='*' -cf - -S -C %s -p --no-recursion --files-from - | tar --xattrs --xattrs-include='*' -xhf - -C %s" % (src, src, dst)
with
cmd = "cd %s; find . -type d -print | tar c --xattrs -f - -S -C %s -p --no-recursion --files-from - | tar x --xattrs -f - -C %s" % (src, src, dst)


Not sure if there's any unwanted side effects from using libarchive tar -- so not sure if this should be fixed the way I've described (with a check for which tar implementation is being used) or simply with a check for different tar implementations instead of hardcoding that "tar" is the one to use.

All distros I've checked that use a different implementation as their default tar have GNU tar available in their repositories as well (by another name, typically gtar).
Comment 1 Richard Purdie 2021-01-28 13:47:36 UTC 
If you change the "tar" link created in HOSTTOOLS to point at gtar it would probably resolve this. Not sure how to do that cleanly but we could document it and suggest it to people with this issue. Which distros is this an issue on?
Comment 2 Randy MacLeod 2021-01-28 15:44:08 UTC 
We may just document this limitation or add a sanity check and refuse to continue unless tar is gtar.