[OE-core] [PATCH v2] mtd-utils: disable xattr if DISTRO_FEATURES doesn't contain acl

[Huang, Jie (Jackie)]

> -----Original Message-----
> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> Sent: Thursday, August 27, 2015 12:04 AM
> To: Huang, Jie (Jackie); Hatle, Mark
> Cc: Andrea Adami; openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH v2] mtd-utils: disable xattr if DISTRO_FEATURES doesn't contain acl
> 
> On Wed, 2015-08-26 at 09:50 +0000, Huang, Jie (Jackie) wrote:
> >
> > > -----Original Message-----
> > > From: openembedded-core-bounces at lists.openembedded.org
> > > [mailto:openembedded-core- bounces at lists.openembedded.org] On Behalf
> > > Of Andrea Adami
> > > Sent: Sunday, August 23, 2015 5:59 AM
> > > To: openembedded-core at lists.openembedded.org
> > > Subject: [OE-core] [PATCH v2] mtd-utils: disable xattr if
> > > DISTRO_FEATURES doesn't contain acl
> > >
> > > After commit 24fde4d do_compile fails:
> > >
> > > | mkfs.jffs2.c:70:21: fatal error: sys/acl.h: No such file or
> > > | directory #include <sys/acl.h>
> > >
> > > This is a missing dependency on acl.
> > > To fix this we add a check to disable xattr when acl is not in DISTRO_FEATURES.
> >
> > I think you should check the xattr distro feature, but only checking
> > the DISTRO_FEATURES can't ensure the dependency satisfied, why not use the PACKAGECONFIG,
> something like:
> >
> > PACKAGECONFIG ?= "${@bb.utils.contains('DISTRO_FEATURES', 'xattr', 'xattr', '', d)}"
> > PACKAGECONFIG[xattr] = ", -DWITHOUT_XATTR,attr acl,"
> 
> I agree that we should check the xattr distro feature. The actual patch is a bit more complex, though,
> because PACKAGECONFIG cannot influence EXTRA_OEMAKE, can it?

Oh, I didn't notice it was for EXTRA_OEMAKE.

> 
> I'll reply with a patch that worked for me.

I see your patch, it looks fine to me.

Thanks,
Jackie

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