Re: [OE-core] [PATCH v4] initramfs-framework: Change recipe to be allarch

[Patrick Ohly]

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.


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4] initramfs-framework: Change recipe to be allarch

[Otavio Salvador]

On Wed, Aug 30, 2017 at 10:24 AM, Patrick Ohly  wrote:
> On Wed, 2017-08-30 at 09:46 -0300, Otavio Salvador wrote:
>> On Wed, Aug 30, 2017 at 6:39 AM, Patrick Ohly > 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.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4] initramfs-framework: Change recipe to be allarch

[Patrick Ohly]

On Wed, 2017-08-30 at 09:46 -0300, Otavio Salvador wrote:
> On Wed, Aug 30, 2017 at 6:39 AM, Patrick Ohly  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.


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4] initramfs-framework: Change recipe to be allarch

[Otavio Salvador]

On Wed, Aug 30, 2017 at 6:39 AM, Patrick Ohly  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 
>> ---
>>
>> 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.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4] initramfs-framework: Change recipe to be allarch

[Patrick Ohly]

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


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v4] initramfs-framework: Change recipe to be allarch

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

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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core