On Mon, 2016-02-01 at 08:57 -0800, Khem Raj wrote:
> On Mon, Feb 1, 2016 at 12:14 AM, Patrick Ohly <patrick.o...@intel.com> wrote:
> > On Mon, 2016-01-25 at 11:39 -0800, Andre McCurdy wrote:
> >> > +        if grep "CONFIG_INIT=y" ${B}/.config; then
> >> > +                install -D -m 0777 ${WORKDIR}/rcS
> >> ${D}${sysconfdir}/init.d/rcS
> >> > +                install -D -m 0777 ${WORKDIR}/rcK
> >> ${D}${sysconfdir}/init.d/rcK
> >> > +                install -D -m 0755 ${WORKDIR}/runlevel
> >> ${D}${base_sbindir}/runlevel
> >> > +                if grep "CONFIG_FEATURE_USE_INITTAB=y"
> >> ${B}/.config; then
> >> > +                        install -D -m 0777 ${WORKDIR}/inittab
> >> ${D}${sysconfdir}/inittab
> >> > +                        tmp="${SERIAL_CONSOLES}"
> >> > +                        for i in $tmp
> >> > +                        do
> >> > +                                j=`echo ${i} | sed s/\;/\ /g`
> >> > +                                label=`echo ${i} | sed -e 's/tty//'
> >> -e 's/^.*;//' -e 's/;.*//'`
> >> > +                                echo "tty$label::respawn:
> >> ${base_sbindir}/getty ${j}" >> ${D}${sysconfdir}/inittab
> >> > +                        done
> >> > +                fi
> >> > +        fi
> >
> > SERIAL_CONSOLES is typically set differently for different machines. But
> > busybox is not machine-specific, therefore using SERIAL_CONSOLE like
> > this prevents sstate/package reuse or worse, causes package versioning
> > problems.
> 
> when busybox is used as init system then it becomes machine specific and we 
> have
> a choice to do so which is disabled by default.

In my case, busybox is not the init system and the recipe is therefore
not machine specific. But the code above is active and thus introduces a
sstate dependency on the machine-specific SERIAL_CONSOLES anyway, even
though the code is dead (if check never reaches it).

The code would have to be added conditionally, and only when it is okay
to reference ${SERIAL_CONSOLES}.

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

Reply via email to