* [PATCH v4] initramfs-framework: Change recipe to be allarch
@ 2017-08-29 20:43 Otavio Salvador
2017-08-30 9:39 ` Patrick Ohly
0 siblings, 1 reply; 6+ messages in thread
From: Otavio Salvador @ 2017-08-29 20:43 UTC (permalink / raw)
To: OpenEmbedded Core Mailing List; +Cc: Otavio Salvador
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
meta/conf/layer.conf | 6 +++++-
meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb | 8 ++------
2 files changed, 7 insertions(+), 7 deletions(-)
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 \
liberation-fonts->fontconfig \
cantarell-fonts->fontconfig \
gnome-icon-theme->librsvg \
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
index 9d69a696f1..77b2ff8959 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
@@ -3,13 +3,9 @@ LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
RDEPENDS_${PN} += "${VIRTUAL-RUNTIME_base-utils}"
-PR = "r2"
+PR = "r3"
-# While the packages maybe an allarch due to it being a
-# simple script, reality is that it is Host specific based
-# on the COMPATIBLE_HOST below, which needs to take precedence
-#inherit allarch
-INHIBIT_DEFAULT_DEPS = "1"
+inherit allarch
SRC_URI = "file://init \
file://rootfs \
--
2.14.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v4] initramfs-framework: Change recipe to be allarch
2017-08-29 20:43 [PATCH v4] initramfs-framework: Change recipe to be allarch Otavio Salvador
@ 2017-08-30 9:39 ` Patrick Ohly
2017-08-30 12:46 ` Otavio Salvador
2017-09-01 6:45 ` Patrick Ohly
0 siblings, 2 replies; 6+ messages in thread
From: Patrick Ohly @ 2017-08-30 9:39 UTC (permalink / raw)
To: Otavio Salvador, OpenEmbedded Core Mailing List
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4] initramfs-framework: Change recipe to be allarch
2017-08-30 9:39 ` Patrick Ohly
@ 2017-08-30 12:46 ` Otavio Salvador
2017-08-30 13:24 ` Patrick Ohly
2017-09-01 6:45 ` Patrick Ohly
1 sibling, 1 reply; 6+ messages in thread
From: Otavio Salvador @ 2017-08-30 12:46 UTC (permalink / raw)
To: Patrick Ohly; +Cc: Otavio Salvador, OpenEmbedded Core Mailing List
On Wed, Aug 30, 2017 at 6:39 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> 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 tend to agree that it should be split out and depends on base.
> I was in a hurry at the time and therefore didn't file a bug, but I can
> also do that.
Sure.
>> 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.
I think this can be in two steps. Splitting it out makes sense as it
avoids the build of useless packages if someone is not using the live
modules but it can be another patch.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4] initramfs-framework: Change recipe to be allarch
2017-08-30 12:46 ` Otavio Salvador
@ 2017-08-30 13:24 ` Patrick Ohly
2017-08-30 13:29 ` Otavio Salvador
0 siblings, 1 reply; 6+ messages in thread
From: Patrick Ohly @ 2017-08-30 13:24 UTC (permalink / raw)
To: Otavio Salvador; +Cc: Otavio Salvador, OpenEmbedded Core Mailing List
On Wed, 2017-08-30 at 09:46 -0300, Otavio Salvador wrote:
> On Wed, Aug 30, 2017 at 6:39 AM, Patrick Ohly <patrick.ohly@intel.co
> wrote:
> > 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.
>
> I think this can be in two steps. Splitting it out makes sense as it
> avoids the build of useless packages if someone is not using the live
> modules but it can be another patch.
I'm not sure in which order you want to get it done: first split out,
then update (i.e. remove the layer.conf change) your patch and merge
that, or apply the v4 revision of your patch and later clean up
(including removal of the layer.conf change)?
Personally I'm in favor of first splitting out the modules.
--
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4] initramfs-framework: Change recipe to be allarch
2017-08-30 13:24 ` Patrick Ohly
@ 2017-08-30 13:29 ` Otavio Salvador
0 siblings, 0 replies; 6+ messages in thread
From: Otavio Salvador @ 2017-08-30 13:29 UTC (permalink / raw)
To: Patrick Ohly, California Sullivan
Cc: Otavio Salvador, OpenEmbedded Core Mailing List
On Wed, Aug 30, 2017 at 10:24 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> On Wed, 2017-08-30 at 09:46 -0300, Otavio Salvador wrote:
>> On Wed, Aug 30, 2017 at 6:39 AM, Patrick Ohly <patrick.ohly@intel.co
>> wrote:
>> > 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.
>>
>> I think this can be in two steps. Splitting it out makes sense as it
>> avoids the build of useless packages if someone is not using the live
>> modules but it can be another patch.
>
> I'm not sure in which order you want to get it done: first split out,
> then update (i.e. remove the layer.conf change) your patch and merge
> that, or apply the v4 revision of your patch and later clean up
> (including removal of the layer.conf change)?
>
> Personally I'm in favor of first splitting out the modules.
I am not in the mood of splitting it now; I prefer California (who
send the additions) does that.
In any case this patch avoids a sstate change for no reason.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4] initramfs-framework: Change recipe to be allarch
2017-08-30 9:39 ` Patrick Ohly
2017-08-30 12:46 ` Otavio Salvador
@ 2017-09-01 6:45 ` Patrick Ohly
1 sibling, 0 replies; 6+ messages in thread
From: Patrick Ohly @ 2017-09-01 6:45 UTC (permalink / raw)
To: Otavio Salvador, OpenEmbedded Core Mailing List
On Wed, 2017-08-30 at 11:39 +0200, Patrick Ohly wrote:
> 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.
See https://bugzilla.yoctoproject.org/show_bug.cgi?id=12024
--
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-09-01 6:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-08-29 20:43 [PATCH v4] initramfs-framework: Change recipe to be allarch Otavio Salvador
2017-08-30 9:39 ` Patrick Ohly
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox