Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: Patrick Ohly <patrick.ohly@intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 3/3] mtd-utils: keep xattr support enabled
Date: Tue, 25 Aug 2015 14:49:04 -0500	[thread overview]
Message-ID: <55DCC6B0.4030105@windriver.com> (raw)
In-Reply-To: <1440516456.24929.78.camel@intel.com>

On 8/25/15 10:27 AM, Patrick Ohly wrote:
> 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?
> 

I think that depends entirely on the dependencies in the package.  I've seen a
few things that do acl w/o requiring xattr.. but they're usually linked together.

It sounds like at a minimum xattr should be the PACKAGECONFIG based on the xattr
distro feature.

--Mark


  reply	other threads:[~2015-08-25 19:49 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 [this message]
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=55DCC6B0.4030105@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=patrick.ohly@intel.com \
    /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