[poky] busybox & update-alternatives

[Mark Hatle]

On 2/11/11 12:24 PM, Gary Thomas wrote:
> On 02/11/2011 10:41 AM, Tom Rini wrote:
>> On 02/11/2011 09:53 AM, Gary Thomas wrote:
>>> A build for my platform with today's master
>>> 49a18f1748d2417958b8e19cdd58c0c79f4fc728
>>> shows a new behaviour - many messages like this:
>>> update-alternatives: Linking //usr/bin/wc to ../../bin/busybox
>>>
>>> Questions:
>>> * Is this truly new or was it just quiet before?
>>> * Can't this be done at image build time? On my little
>>> embedded OMAP-L138, it takes nearly 2 minutes to run
>>> through this. My root is a ramdisk, so this is a cost
>>> I see on _every_ boot.
>>> * If it can't be done at build time, can I disable it?
>>
>> It can be done at build time _except_ for when there's a conflict. I suspect what's going on is that a recent change has introduced a conflict (which is to say, busybox provides
>> foo as an alternative and something else also provides it, but isn't registering it as an alternative). If you check the whole boot log (or log.do_rootfs) you can find where the
>> conflict is and then do something like http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=902b98f32ffd35661e43382f47226f65528ff1b1 (it's a little more complicated if the
>> recipe also does BBCLASSEXTEND, since you don't want to do the move for virtclass-foo).
> 
> Running the postinst script manually, I get this error:
> 
> + update-rc.d -s syslog busybox-udhcpc defaults
> usage: update-rc.d [-n] [-f] [-r <root>] <basename> remove
>         update-rc.d [-n] [-r <root>] [-s] <basename> defaults [NN | sNN kNN]
>         update-rc.d [-n] [-r <root>] [-s] <basename> start|stop NN runlvl [runlvl] [...] .
>                  -n: not really
>                  -f: force
>                  -v: verbose
>                  -r: alternate root path (default is /)
>                  -s: invoke start methods if appropriate to current runlevel
> 
> Looks like update-rc.d is not being called properly.  This
> was introduced by
>    commit 427472e980cd6254a5e4ef37209b327e15af259b
>    Author: Mark Hatle <mark.hatle at windriver.com>
>    Date:   Thu Feb 3 19:29:50 2011 -0600
> 
> Mark, any comments?
> 

The error is coming from the INITSCRIPT_NAME_${PN} change.  However, I don't
know how to resolve it.  Where there was previously only one init script, there
are now two.  So how do we inform bitbake that there are two initscripts to be
processed?

(If specifying more then one initscript is correct in the recipe, then the bug
is in a class wherever update-rc.d is called.)

--Mark