Re: busybox & update-alternatives

[Gary Thomas <gary@mlbassoc.com>]

On 02/11/2011 12:46 PM, Mark Hatle wrote:
> On 2/11/11 1:22 PM, Gary Thomas wrote:
>> On 02/11/2011 11:37 AM, Mark Hatle wrote:
>>> On 2/11/11 12:30 PM, Mark Hatle wrote:
>>>> 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@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?
>>>
>>> I asked and it appears there is a limitation of one initscript per split
>>> package.  So as a workaround, I suggest removing the busybox-udhcpc from the
>>> INITSCRIPTS_NAME_${PN} line..
>>
>> The attached patch looks like it does the right thing.  Any reason it's not
>> the way to fix this?
>
> That patch should work fine.  Only concern is if you have multiple initscripts
> with different params.. how do you reconcile that.  (Simplest answer for me
> would be ${INITSCRIPT_PARAMS_name} --- but I'm guessing that might clash with
> the package names and cause other problems.
>
> I'm exploring adding a -sysroot as well as -udhcpc split package.  But so far
> I'm not having much success getting the semantics right....

Since you're working on this, I'll leave the final solution to you :-)

I have a [temporary] solution for now.

Thanks

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

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------