[OE-core] [PATCH 1/1] update-rc.d.bbclass: change RRECOMMENDS to RDEPENDS

ChenQi Qi.Chen at windriver.com
Fri Sep 13 01:53:51 UTC 2013


On 09/12/2013 08:18 PM, Martin Jansa wrote:
> On Thu, Sep 12, 2013 at 07:18:12PM +0800, ChenQi wrote:
>> On 09/12/2013 06:25 PM, Martin Jansa wrote:
>>> On Thu, Sep 12, 2013 at 05:43:55PM +0800, Qi.Chen at windriver.com wrote:
>>>> From: Chen Qi <Qi.Chen at windriver.com>
>>>>
>>>> If a package inherits update-rc.d.bbclass, it actually needs it to
>>>> update the symlinks under /etc/rc?.d/ directories. This is a runtime
>>>> dependency. For example, if we try to upgrade the dropbear on target,
>>>> its postinst process will need the update-rc.d utility available,
>>>> otherwise, the upgrade process will fail.
>>>>
>>>> Besides, if we only recommend update-rc.d, the do_rootfs process will
>>>> fail once NO_RRECOMMENDATIONS is enabled. Because in OE, we try to do
>>>> the postinsts at rootfs time.
>>> IIRC it was changed to allow systemd images to be built completely
>>> without update-rc.d (with BAD_RECOMMENDATIONS += "update-rc.d") and it's
>>> IMHO still valid use-case as update-rc.d is inherited even when systemd
>>> is used.
>>>
>> Now that the 'rm_sysvinit_initdir' function has been added to the
>> systemd.bbclass, I think we can safely use RDEPENDS here. Because
>> 1) If the /etc/init is removed, update-rc.d command in postinst has no
>> real effect.
>> 2) If the /etc/init is not removed, that means symlinks under
>> /etc/rc?.d/ should be set up.
>>
>> So I think there's no negative effect if update-rc.d is installed in
>> case of a systemd system.
>>
>> Also, I don't think adding update-rc.d to BAD_RECOMMENDATIONS is a good
>> idea.
>> For example, we have a systemd based image running and we are installing
>> a new package to that image. That package has an init script but no
>> corresponding service file. If we only recommend update-rc.d and it's in
>> BAD_RECOMMENDATIONS, the install process will fail. This is not what
>> user might expect.
>>
>> So I'd like to suggest that we change it back to RDEPENDS.
> commit 2c403979c03898c679c5a1e1092aec784dbeb77c
> Author: Ross Burton <ross.burton at intel.com>
> Date:   Tue Mar 5 11:57:00 2013 +0000
>
> update-rcd: drop depends to recommends, check for update-rcd in scripts
>
> This class is still checking if update-rc.d is installed before using
> it, so nothing should fail terribly if image developer decides that he
> want's image without any sysvinit related stuff.
>
> If you want image which supports both you can add runtime dependency on
> update-rc.d somewhere else - it doesn't need to be pulled by every
> recipe which inherits update-rc.d bbclass.

Thanks, Martin.

I think I made a mistake.
The real cause is that in image.bbclass, the rootfs_uninstall_unneeded 
function tries to remove the update-rc.d package but it's not installed 
because NO_RECOMMENDATIONS is enabled.
I'm gonna remove update-rc.d from the uninstall list in that function.
Patch will be sent out soon.

Thanks a lot,
Chen Qi


>> Best Regards,
>> Chen Qi
>>
>>>> This patch fixes this problem by changing the RRECOMMENDS to RDEPENDS
>>>> to let the packages actually rdepend on update-rc.d.
>>>>
>>>> [YOCTO #5169]
>>>>
>>>> Signed-off-by: Chen Qi <Qi.Chen at windriver.com>
>>>> ---
>>>>    meta/classes/update-rc.d.bbclass |    2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
>>>> index 5588569..3dee13a 100644
>>>> --- a/meta/classes/update-rc.d.bbclass
>>>> +++ b/meta/classes/update-rc.d.bbclass
>>>> @@ -6,7 +6,7 @@ UPDATERCD_virtclass-cross = ""
>>>>    UPDATERCD_class-native = ""
>>>>    UPDATERCD_class-nativesdk = ""
>>>>    
>>>> -RRECOMMENDS_${UPDATERCPN}_append = " ${UPDATERCD}"
>>>> +RDEPENDS_${UPDATERCPN}_append = " ${UPDATERCD}"
>>>>    
>>>>    INITSCRIPT_PARAMS ?= "defaults"
>>>>    
>>>> -- 
>>>> 1.7.9.5
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core at lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core




More information about the Openembedded-core mailing list