[OE-core] [PATCH] meta/conf/layer.conf: adapt to more flexible initramfs-framework RDEPENDS

[Patrick Ohly]

On Tue, 2016-02-09 at 10:22 +0100, Patrick Ohly wrote:
> On Mon, 2016-02-08 at 16:14 +0100, Patrick Ohly wrote:
> > initramfs-framework now RDEPENDS on ${VIRTUAL-RUNTIME_base-utils},
> > which can be busybox or some alternative like toybox. Making the
> > SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS exception flexible, too, ensures that
> > distros using toybox still pass the selftests.
> > 
> > Signed-off-by: Patrick Ohly <patrick.ohly at intel.com>
> > ---
> >  meta/conf/layer.conf | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> > index 7100ed7..baa4fd4 100644
> > --- a/meta/conf/layer.conf
> > +++ b/meta/conf/layer.conf
> > @@ -46,7 +46,7 @@ SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \
> >    ppp-dialin->ppp \
> >    resolvconf->bash \
> >    docbook-xsl-stylesheets->perl \
> > -  initramfs-framework->busybox \
> > +  initramfs-framework->${VIRTUAL-RUNTIME_base-utils} \
> >    initramfs-framework->systemd \
> >    initramfs-framework->udev \
> >    liberation-fonts->fontconfig \
> 
> Was VIRTUAL-RUNTIME_base-utils meant to be a single word?

Apparently it was, for the sake of consistency with other
VIRTUAL-RUNTIME variables.

> I just noticed that toybox does not provide a /bin/sh out-of-the-box,
> and even when enabled the resulting sh is not complete enough to execute
> initramfs-framework scripts.
> 
> That means that VIRTUAL-RUNTIME_base-utils = "toybox" leads to an
> unusable initramfs when replacing "busybox" with
> ${VIRTUAL-RUNTIME_base-utils} in initramfs-framwork.

A better fix is probably to make toybox a full replacement (eventually)
or make it RDEPEND on the missing pieces (current solution, for those
who want it as busybox replacement).

> This could be fixed by setting
>   VIRTUAL-RUNTIME_base-utils = "toybox dash"
> but then the patch above needs to be fixed.

No, let's keep the patch as it is.

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