[OE-core] [PATCH 3/3] mtd-utils: keep xattr support enabled

[Mark Hatle]

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

This is typically how I've seen it implemented in other places.  (Not necessary
xattr.. but with the push for more Linux Security Models coming from users and
other layers, I think xattr is something we need to make sure really works
properly.)

--Mark