Bug 14205 - [Poky] Poky's sanity.bbclass and path.py assume tar is gtar
Summary: [Poky] Poky's sanity.bbclass and path.py assume tar is gtar
Status: RESOLVED FIXED
Alias: None
Product: Other YP Layers
Classification: Build System, Metadata & Runtime
Component: layers (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: Future
Assignee: Simone Weiß
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2021-01-27 17:55 UTC by Bernhard Rosenkränzer
Modified: 2024-06-05 19:21 UTC (History)
5 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.