[PATCH 1/1] systemd-compat-units: do not inherit allarch

[PATCH 1/1] systemd-compat-units: do not inherit allarch

[Joe Slater]

Even though we are just a script, we do depend on
systemd being on the target and need an RDEPENDS
which means we cannot also be allarch.

Signed-off-by: Joe Slater <jslater@windriver.com>
---
 meta/recipes-core/systemd/systemd-compat-units.bb |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd-compat-units.bb b/meta/recipes-core/systemd/systemd-compat-units.bb
index f246e83..421fc06 100644
--- a/meta/recipes-core/systemd/systemd-compat-units.bb
+++ b/meta/recipes-core/systemd/systemd-compat-units.bb
@@ -9,7 +9,7 @@ DEPENDS = "systemd-systemctl-native"
 
 S = "${WORKDIR}"
 
-inherit allarch distro_features_check
+inherit distro_features_check
 
 ALLOW_EMPTY_${PN} = "1"
 
-- 
1.7.9.5

Re: [PATCH 1/1] systemd-compat-units: do not inherit allarch

[Patrick Ohly]

On Mon, 2016-08-22 at 15:12 -0700, Joe Slater wrote:
> Even though we are just a script, we do depend on
> systemd being on the target and need an RDEPENDS
> which means we cannot also be allarch.
> 
> Signed-off-by: Joe Slater <jslater@windriver.com>
> ---
>  meta/recipes-core/systemd/systemd-compat-units.bb |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/systemd/systemd-compat-units.bb b/meta/recipes-core/systemd/systemd-compat-units.bb
> index f246e83..421fc06 100644
> --- a/meta/recipes-core/systemd/systemd-compat-units.bb
> +++ b/meta/recipes-core/systemd/systemd-compat-units.bb
> @@ -9,7 +9,7 @@ DEPENDS = "systemd-systemctl-native"
>  
>  S = "${WORKDIR}"
>  
> -inherit allarch distro_features_check
> +inherit distro_features_check

+1 from me. The alternative solution would be to add
"systemd-compat-units->systemd" to SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS in
meta/conf/layer.conf, but that's more complicated and probably not worth
it.

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