Message-ID: <1501578916.18875.39.camel@intel.com>
From: Patrick Ohly <patrick.ohly@intel.com>
To: Armin Kuster <akuster808@gmail.com>, akuster@mvista.com, 
	yocto@yoctoproject.org
Date: Tue, 01 Aug 2017 11:15:16 +0200
In-Reply-To: <1501513583-13585-1-git-send-email-akuster808@gmail.com>
References: <1501513583-13585-1-git-send-email-akuster808@gmail.com>
Organization: Intel GmbH, Dornacher Strasse 1, D-85622 Feldkirchen/Munich
Mime-Version: 1.0
Subject: Re: [meta-security][PATCH] layer: remove TPM layer depends and other dynamic ones.
Precedence: list
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

On Mon, 2017-07-31 at 08:06 -0700, Armin Kuster wrote:
> include meta-python for AppArmor changes
> 
> Signed-off-by: Armin Kuster <akuster808@gmail.com>
> ---
>  conf/layer.conf | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/conf/layer.conf b/conf/layer.conf
> index 0e524a1..0b066fd 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -9,8 +9,4 @@ BBFILE_COLLECTIONS += "security"
>  BBFILE_PATTERN_security = "^${LAYERDIR}/"
>  BBFILE_PRIORITY_security = "6"
>  
> -LAYERDEPENDS_security = "core openembedded-layer perl-layer"
> -LAYERDEPENDS_security += "${@bb.utils.contains("DISTRO_FEATURES",
> "x11", "gnome-layer xfce-layer", "", d)}"
> -LAYERDEPENDS_security += "${@bb.utils.contains("MACHINE_FEATURES",
> "tpm", "tpm-layer", "",d)}"
> -LAYERDEPENDS_security += "${@bb.utils.contains("MACHINE_FEATURES",
> "tpm2", "tpm-layer", "",d)}"
> -LAYERDEPENDS_security += "${@bb.utils.contains("MACHINE_FEATURES",
> "vtpm", "tpm-layer meta-filesystems", "",d)}"
> +LAYERDEPENDS_security = "core openembedded-layer perl-layer meta-
> python"

How does this affect recipes which depend on some of things in those
layers?

I suspect that using meta-security without those other layers now
results in a broken world build due to missing dependencies.

-- 
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.