From: Patrick Ohly <patrick.ohly@intel.com>
To: Otavio Salvador <otavio@ossystems.com.br>,
OpenEmbedded Core Mailing List
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH v4] initramfs-framework: Change recipe to be allarch
Date: Wed, 30 Aug 2017 11:39:56 +0200 [thread overview]
Message-ID: <1504085996.12799.39.camel@intel.com> (raw)
In-Reply-To: <20170829204309.16139-1-otavio@ossystems.com.br>
On Tue, 2017-08-29 at 17:43 -0300, Otavio Salvador wrote:
> There is no COMPATIBLE_HOST in the recipe neither it makes sense for
> this to be machine specific.
>
> Possibly, initramfs-framework's based modules may be machine specific
> but if there is the case they can just RDEPENDS on
> initramfs-framework-base and provide the specific module as another
> recipe.
>
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
>
> Changes in v4:
> - Drop INHIBIT_DEFAULT_DEPS as allarch defines it
>
> Changes in v3:
> - Add the new dependencies to the hash whitelist
As I said before ("Re: [OE-core] [PATCH v6 1/1] initramfs-framework:
module to support boot live image" from July 31st), I consider it a
mistake that support for live boot with all its dependencies was added
directly to initramfs-framework.bb.
I was in a hurry at the time and therefore didn't file a bug, but I can
also do that.
> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> index 38bec33197..04aa730160 100644
> --- a/meta/conf/layer.conf
> +++ b/meta/conf/layer.conf
> @@ -50,8 +50,12 @@ SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \
> docbook-xsl-stylesheets->perl \
> ca-certificates->openssl \
> initramfs-framework->${VIRTUAL-RUNTIME_base-utils} \
> - initramfs-framework->systemd \
> + initramfs-framework->dosfstools \
> + initramfs-framework->e2fsprogs \
> initramfs-framework->eudev \
> + initramfs-framework->parted \
> + initramfs-framework->systemd \
> + initramfs-framework->util-linux \
Let's not dig us deeper into this hole and instead split out the live
boot module into its own, arch-specific recipe.
Then initramfs-framework can become allarch without having to make
layer.conf more complicated.
--
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.
next prev parent reply other threads:[~2017-08-30 9:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-29 20:43 [PATCH v4] initramfs-framework: Change recipe to be allarch Otavio Salvador
2017-08-30 9:39 ` Patrick Ohly [this message]
2017-08-30 12:46 ` Otavio Salvador
2017-08-30 13:24 ` Patrick Ohly
2017-08-30 13:29 ` Otavio Salvador
2017-09-01 6:45 ` Patrick Ohly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1504085996.12799.39.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio@ossystems.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.