Openembedded Core Discussions
 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 3/3] mtd-utils: keep xattr support enabled
Date: Tue, 25 Aug 2015 17:27:36 +0200	[thread overview]
Message-ID: <1440516456.24929.78.camel@intel.com> (raw)
In-Reply-To: <55DC6D05.7010107@windriver.com>

On Tue, 2015-08-25 at 08:26 -0500, Mark Hatle wrote:
> On 8/25/15 6:46 AM, Patrick Ohly wrote:
> > On Fri, 2015-08-14 at 11:51 +0100, Burton, Ross wrote:
> >>
> >> On 12 August 2015 at 10:33, Patrick Ohly <patrick.ohly@intel.com>
> >> wrote:
> >>         > There's a "xattr" DISTRO_FEATURE that should be respected
> >>         here for
> >>         > target builds (and explicitly enabled for native I guess).
> >>         
> >>         I can add that check, if you want.
> >>         
> >>         > Does enabling xattr mean adding build dependencies?
> >>         
> >>         No, the conditional code uses lgetxattr and llistxattr, which
> >>         are in
> >>         glibc.
> >>
> >>
> >> From five seconds of google it looks like these are in musl and uclibc
> >> too, so I've merged this  to MUT as-is.
> > 
> > However, it turned out that the XATTR code also introduces a dependency
> > on sys/acl.h:
> > 
> > mkfs.jffs2.c:
> > 
> > #ifndef WITHOUT_XATTR
> > #include <sys/xattr.h>
> > #include <sys/acl.h>
> > #endif
> > 
> > sys/acl.h gets provided by acl, so it may or may not work depending on
> > build order and files on the host.
> > 
> > I hadn't caught that because I had only looked at library dependencies,
> > sorry for that.
> > 
> > What's the right fix? Add the dependency on acl-native in the native
> > case, disable XATTR support for target builds (same state as before) or
> > make it somehow depend on both "xattr" and "acl" distro features?
> > 
> > Or only check for "xattr"? I'm uncertain how the two are related.
> > 
> 
> Use PACKAGECONFIG, add xattr as a configuration that in turn adds the 'acl' as a
> dependency.  Then acl-native will automatically be converted from 'acl' if the
> '-native' version is built.

I agree, a PACKAGECONFIG sounds like the right approach. However, what
should the default depend on? The "xattr" or "acl" distro feature? What
if someone wants xattr, but not acl? Should xattr support in mtd-utils
be enabled in that case even though it pulls in the acl recipe as
dependency?

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





  parent reply	other threads:[~2015-08-25 15:27 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 [this message]
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

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=1440516456.24929.78.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox