From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13]) by mail.openembedded.org (Postfix) with ESMTP id 5DF1665CCD for ; Tue, 25 Aug 2015 19:49:06 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.15.2/8.15.1) with ESMTPS id t7PJn64T022812 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Aug 2015 12:49:06 -0700 (PDT) Received: from Marks-MacBook-Pro-2.local (172.25.36.227) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.235.1; Tue, 25 Aug 2015 12:49:05 -0700 To: Patrick Ohly References: <6af40fe1752b8cf25efca4a906361c4437249841.1439281753.git.patrick.ohly@intel.com> <1439372036.28153.29.camel@intel.com> <1440503201.24929.53.camel@intel.com> <55DC6D05.7010107@windriver.com> <1440516456.24929.78.camel@intel.com> From: Mark Hatle Organization: Wind River Systems Message-ID: <55DCC6B0.4030105@windriver.com> Date: Tue, 25 Aug 2015 14:49:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1440516456.24929.78.camel@intel.com> Cc: openembedded-core@lists.openembedded.org Subject: Re: [PATCH 3/3] mtd-utils: keep xattr support enabled X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 19:49:07 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 >>>> 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 >>> #include >>> #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