All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Ohly <patrick.ohly@intel.com>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 0/3] preserve xattrs in images
Date: Wed, 12 Aug 2015 16:44:25 +0200	[thread overview]
Message-ID: <1439390665.28153.41.camel@intel.com> (raw)
In-Reply-To: <55CB5960.9010708@windriver.com>

On Wed, 2015-08-12 at 09:34 -0500, Mark Hatle wrote:
> Is there something here that enables the tar-replacement-native?  Or is the user
> just expected to know they need it?

The user is supposed to ensure that it gets depended on if (and only if)
needed.

I gave the following usage instructions in the comments of the
image_types.bbclass patch:

+# By default, tar from the host is used, which can be quite old. If
+# you need special parameters (like --xattrs) which are only supported
+# by GNU tar upstream >= 1.27, then override that default:
+# IMAGE_CMD_TAR = "tar-native --xattrs --xattrs-include=*"
+# IMAGE_DEPENDS_tar_append = " tar-replacement-native"

> If you look at meta/classes/sanity.bbclass, there is already a tar check for a
> specific old version that can't handle overwriting symlinks properly.  It should
> be possible to check for the distro feature of xattr and that the host tar has
> this.  It would be good to prevent the user from having a problem early (sanity)
> rather then at filesystem generation time.

The way the patch series is intended to be used at the moment, the user
will not have a problem regardless of the host tar, because image
creation will always use a recent enough tar. It might build
tar-replacement-native unnecessarily, though.

A distro might also impose additional restrictions on the host's tar and
then will not need to be build tar-replacement-native; I haven't tried
that, because I'd still like to be compatible with Debian 7 which would
fail the requirement.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





      reply	other threads:[~2015-08-12 14:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-11  8:44 [PATCH 0/3] preserve xattrs in images Patrick Ohly
2015-08-11  8:44 ` [PATCH 1/3] tar-replacement-native: avoid race condition with host tar Patrick Ohly
2015-08-14 10:47   ` Burton, Ross
2015-08-14 11:01     ` Paul Eggleton
2015-08-14 11:03       ` Burton, Ross
2015-08-14 14:52         ` Patrick Ohly
2015-08-14 14:56           ` Paul Eggleton
2015-08-14 15:38             ` Patrick Ohly
2015-08-14 16:29               ` Paul Eggleton
2015-08-14 14:59           ` [PATCH v2 0/2] xattr + tar Patrick Ohly
2015-08-14 14:59             ` [PATCH v2 1/2] tar-replacement-native: relocate via NATIVE_PACKAGE_PATH_SUFFIX Patrick Ohly
2015-08-14 15:07               ` Burton, Ross
2015-08-14 16:01                 ` [PATCH v3 0/2] xattr + tar Patrick Ohly
2015-08-14 16:01                   ` [PATCH v3 1/2] tar-replacement-native: relocate via NATIVE_PACKAGE_PATH_SUFFIX Patrick Ohly
2015-08-14 16:01                   ` [PATCH v3 2/2] image_types.bbclass: allow replacing tar command Patrick Ohly
2015-08-14 14:59             ` [PATCH v2 " Patrick Ohly
2015-08-11  8:44 ` [PATCH 2/3] " Patrick Ohly
2015-08-11  8:45 ` [PATCH 3/3] mtd-utils: keep xattr support enabled Patrick Ohly
2015-08-11 14:33   ` Burton, Ross
2015-08-12  9:33     ` Patrick Ohly
2015-08-14 10:51       ` Burton, Ross
2015-08-25 11:46         ` Patrick Ohly
2015-08-25 13:26           ` Mark Hatle
2015-08-25 13:46             ` Andrea Adami
2015-08-25 15:27             ` Patrick Ohly
2015-08-25 19:49               ` Mark Hatle
2015-08-11 14:29 ` [PATCH 0/3] preserve xattrs in images Burton, Ross
2015-08-12  9:28   ` Patrick Ohly
2015-08-12 14:34 ` Mark Hatle
2015-08-12 14:44   ` Patrick Ohly [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1439390665.28153.41.camel@intel.com \
    --to=patrick.ohly@intel.com \
    --cc=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.