Re: busybox & update-alternatives

[Tom Rini <tom_rini@mentor.com>]

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

-- 
Tom Rini
Mentor Graphics Corporation