[OE-core] [PATCH] initramfs-framework: split setup-live and install-efi into separate recipes

Otavio Salvador otavio.salvador at ossystems.com.br
Mon Sep 4 13:25:17 UTC 2017


On Mon, Sep 4, 2017 at 10:07 AM, Patrick Ohly <patrick.ohly at intel.com> wrote:
> On Mon, 2017-09-04 at 09:46 -0300, Otavio Salvador wrote:
>> On Mon, Sep 4, 2017 at 3:35 AM, Patrick Ohly <patrick.ohly at intel.com>
>> wrote:
>> > On Sat, 2017-09-02 at 15:17 -0300, Otavio Salvador wrote:
>> > > On Fri, Sep 1, 2017 at 9:04 PM, California Sullivan
>> > > <california.l.sullivan at intel.com> wrote:
>> > > > Having these the initramfs-framework recipe
>> > > > forced initramfs-framework
>> > > > users to build several tools they didn't need, and made it more
>> > > > difficult to declare the recipe as allarch.
>> > > >
>> > > > Fixes [YOCTO #12024].
>> > > >
>> > > > Signed-off-by: California Sullivan <california.l.sullivan at intel
>> > > > .com
>> > > > >
>> > >
>> > > The patch should be based on the allarch patch I sent as it adds
>> > > the
>> > > dependencies on the whitelist. So you can also set them as
>> > > allarch.
>> >
>> > I would prefer to keep initramfs-framework-setup-live/install-efi
>> > as
>> > arch-specific and only make initramfs-framework itself allarch.
>> > It's
>> > just a gut feeling about the (minor) advantage of not having to
>> > rebuild
>> > these two small recipes vs. the additional complexity of the
>> > layer.conf
>> > and having to keep that up-to-date.
>>
>> The recipe is a shell script and there is no reason to not make it
>> allarch. The need to keep layer.conf up to date is minor as it is
>> going to be need only when new dependencies are added. Not ofthen...
>
> The need for that was already missed once, in the initial patch which
> introduced "inherit allarch". I find it likely that whoever changes the
> scripts in the future will also miss it, causing additional work for
> those who then have to deal with the auto builder errors. At least add
> a comment to the DEPENDS which explains that layer.conf needs to be
> edited together with the recipe(s).
>
> But that's just my opinion. If Richard and/or Ross aren't worried about
> a too complex OE-core layer.conf, then that's fine with me too.

Complexity cannot be an excuse to avoid correctness. Sorry but I don't
buy your argument ...


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