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

Otavio Salvador otavio.salvador at ossystems.com.br
Wed Aug 30 12:46:29 UTC 2017


On Wed, Aug 30, 2017 at 6:39 AM, Patrick Ohly <patrick.ohly at 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 at 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



More information about the Openembedded-core mailing list