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
next prev parent 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