[PATCH] pseudo: explicitly enable xattr support

[PATCH] pseudo: explicitly enable xattr support

[Andreas Kaufmann]

Pseudo is using a custom configure script that detects if it shall build with
extended file attribute support or not. The check is done by simply calling
'getfattr' provided by attr-native which is not part of the dependency list.
Due to the recent changes (recipe specific sysroot & cleanup of $PATH) this
call fails now when the recipe is being build for the first time (at least
when being build for nativesdk case). Explicitly setting up a dependency to
attr-native just to satisfy configure would be wrong also since the real
dependency is to attr/nativesdk-attr which are already part of the dependency
list (see DEPENDS). Therefore bypass the test in the configure by explicitly
enabling xattr using a configure option available in any case.

Signed-off-by: Andreas Kaufmann <andreas.kaufmann.79@gmail.com>
---
 meta/recipes-devtools/pseudo/pseudo.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/pseudo/pseudo.inc b/meta/recipes-devtools/pseudo/pseudo.inc
index fb74252..cdc2a58 100644
--- a/meta/recipes-devtools/pseudo/pseudo.inc
+++ b/meta/recipes-devtools/pseudo/pseudo.inc
@@ -26,7 +26,7 @@ do_configure () {
 NO32LIBS ??= "1"
 NO32LIBS_class-nativesdk = "1"
 
-PSEUDO_EXTRA_OPTS ?= "--enable-force-async --without-passwd-fallback --enable-epoll"
+PSEUDO_EXTRA_OPTS ?= "--enable-force-async --without-passwd-fallback --enable-epoll --enable-xattr"
 
 # Compile for the local machine arch...
 do_compile () {
-- 
2.7.4

Re: [PATCH] pseudo: explicitly enable xattr support

[Seebs]

On Thu, 22 Mar 2018 17:06:08 +0100
Andreas Kaufmann <andreas.kaufmann.79@gmail.com> wrote:

> Pseudo is using a custom configure script that detects if it shall
> build with extended file attribute support or not. The check is done
> by simply calling 'getfattr' provided by attr-native which is not
> part of the dependency list. Due to the recent changes (recipe
> specific sysroot & cleanup of $PATH) this call fails now when the
> recipe is being build for the first time (at least when being build
> for nativesdk case). Explicitly setting up a dependency to
> attr-native just to satisfy configure would be wrong also since the
> real dependency is to attr/nativesdk-attr which are already part of
> the dependency list (see DEPENDS). Therefore bypass the test in the
> configure by explicitly enabling xattr using a configure option
> available in any case.

This seems reasonable to me. The historical rationale for the configure
test was that we encountered actual systems in the wild which did not
have the underlying xattr support, as I recall? But I think that's no
longer remotely relevant.

-s