Patchwork [RFC] udev: add udev-utils to RDEPENDS

login
register
mail settings
Submitter David Nyström
Date Feb. 3, 2014, 12:58 p.m.
Message ID <1391432329-1046-1-git-send-email-david.nystrom@enea.com>
Download mbox | patch
Permalink /patch/66263/
State New
Headers show

Comments

David Nyström - Feb. 3, 2014, 12:58 p.m.
An intended fix for below error message with core-image-lsb, 
Sending this as an RFC since I dont really know what constitutes 
a RRECOMMENDS vs. RDEPENDS. 
Is this clearly defined somewhere ?
Below should be an RDEPENDS, no ?

INIT: version 2.88 booting
Starting udev
udevd[59]: starting version 182
/etc/rcS.d/S04udev: line 108: udevadm: command not found
/etc/rcS.d/S04udev: line 113: udevadm: command not found
/etc/rcS.d/S04udev: line 114: udevadm: command not found

Signed-off-by: David Nyström <david.nystrom@enea.com>
---
 meta/recipes-core/udev/udev.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
Paul Eggleton - Feb. 3, 2014, 1:03 p.m.
Hi David,

On Monday 03 February 2014 13:58:49 David Nyström wrote:
> An intended fix for below error message with core-image-lsb,
> Sending this as an RFC since I dont really know what constitutes
> a RRECOMMENDS vs. RDEPENDS.
> Is this clearly defined somewhere ?
> Below should be an RDEPENDS, no ?

Does this actually fix the problem though? An RRECOMMENDS would only not be 
satisfied if the package ended up empty, or you were using BAD_RECOMMENDATIONS 
(or NO_RECOMMENDATIONS). I can't see this change actually accomplishing 
anything.

Cheers,
Paul
David Nyström - Feb. 3, 2014, 1:21 p.m.
On mån  3 feb 2014 14:03:47, Paul Eggleton wrote:
> Hi David,
>
> On Monday 03 February 2014 13:58:49 David Nyström wrote:
>> An intended fix for below error message with core-image-lsb,
>> Sending this as an RFC since I dont really know what constitutes
>> a RRECOMMENDS vs. RDEPENDS.
>> Is this clearly defined somewhere ?
>> Below should be an RDEPENDS, no ?
>
> Does this actually fix the problem though? An RRECOMMENDS would only not be
> satisfied if the package ended up empty, or you were using BAD_RECOMMENDATIONS
> (or NO_RECOMMENDATIONS). I can't see this change actually accomplishing
> anything.
>
> Cheers,
> Paul
>

Thanks for the quick reply,
I was using --no-recommends, via the opkg package-manager. 
(rootfs-sandbox).

Regarding the split between RRECOMMENDS and RDEPENDS:
In my understanding, RRECOMMENDS would be when the functionality is 
optional,
RDEPENDS when dependency is hard.

To me, this seems like a hard dependency. But a definition between the 
two would be good to have
for future patches.

Br,
David
David Nyström - Feb. 3, 2014, 2:01 p.m.
On mån  3 feb 2014 14:43:53, Phil Blundell wrote:
> On Mon, 2014-02-03 at 13:58 +0100, David Nyström wrote:
>> An intended fix for below error message with core-image-lsb,
>> Sending this as an RFC since I dont really know what constitutes
>> a RRECOMMENDS vs. RDEPENDS.
>> Is this clearly defined somewhere ?
>> Below should be an RDEPENDS, no ?
>>
>> INIT: version 2.88 booting
>> Starting udev
>> udevd[59]: starting version 182
>> /etc/rcS.d/S04udev: line 108: udevadm: command not found
>> /etc/rcS.d/S04udev: line 113: udevadm: command not found
>> /etc/rcS.d/S04udev: line 114: udevadm: command not found
>
> That depends (ha ha) on what the udevadm call in question is actually
> doing.  If udev is so badly broken without it as to be unusable then
> yes, it should be an RDEPENDS.  If udev will still work without then
> RRECOMMENDS is appropriate and the initscript should be tweaked to deal
> with it.
>
> p.
>
>


SNIP
--
    udevadm control --env=STARTUP=1
    if [ "$not_first_boot" != "" ];then
            udevadm trigger --action=add --subsystem-nomatch=tty 
--subsystem-nomatch=mem --subsystem-nomatch=vc 
--subsystem-nomatch=vtconsole --subsystem-nomatch=misc 
--subsystem-nomatch=dcon --subsystem-nomatch=pci_bus  
--subsystem-nomatch=graphics        --subsystem-nomatch=backlight 
--subsystem-nomatch=video4linux  --subsystem-nomatch=platform
            (udevadm settle --timeout=10; udevadm control 
--env=STARTUP=)&
    else
            udevadm trigger --action=add
            udevadm settle
    fi
--
SNIP

Does this classify as essential ?

If essential, we either need to move udev-utils to RDEPENDS.
If not essential, fix the script to detect if udevadm is available.

Br,
David
Martin Jansa - Feb. 3, 2014, 2:19 p.m.
On Mon, Feb 03, 2014 at 02:21:26PM +0100, David Nyström wrote:
> On mån  3 feb 2014 14:03:47, Paul Eggleton wrote:
> > Hi David,
> >
> > On Monday 03 February 2014 13:58:49 David Nyström wrote:
> >> An intended fix for below error message with core-image-lsb,
> >> Sending this as an RFC since I dont really know what constitutes
> >> a RRECOMMENDS vs. RDEPENDS.
> >> Is this clearly defined somewhere ?
> >> Below should be an RDEPENDS, no ?
> >
> > Does this actually fix the problem though? An RRECOMMENDS would only not be
> > satisfied if the package ended up empty, or you were using BAD_RECOMMENDATIONS
> > (or NO_RECOMMENDATIONS). I can't see this change actually accomplishing
> > anything.
> >
> > Cheers,
> > Paul
> >
> 
> Thanks for the quick reply,
> I was using --no-recommends, via the opkg package-manager. 
> (rootfs-sandbox).
> 
> Regarding the split between RRECOMMENDS and RDEPENDS:
> In my understanding, RRECOMMENDS would be when the functionality is 
> optional,
> RDEPENDS when dependency is hard.

Don't forget on RSUGGESTS :)

RDEPENDS - hard dependency
RRECOMMENDS - optional dependency, but good to have in most cases by
default unless it's unavailable (e.g. typical for kernel-modules-*) or
distro/user knows what he is doing and decides to add it in
BAD_RECOMMENDATIONS or removes is on target explicitly
RSUGGESTS - really optional dependency

> To me, this seems like a hard dependency. But a definition between the 
> two would be good to have
> for future patches.
> 
> Br,
> David
> 
> 
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Qi.Chen@windriver.com - June 3, 2014, 6:58 a.m.
On 02/03/2014 10:01 PM, David Nyström wrote:
> On mån  3 feb 2014 14:43:53, Phil Blundell wrote:
>> On Mon, 2014-02-03 at 13:58 +0100, David Nyström wrote:
>>> An intended fix for below error message with core-image-lsb,
>>> Sending this as an RFC since I dont really know what constitutes
>>> a RRECOMMENDS vs. RDEPENDS.
>>> Is this clearly defined somewhere ?
>>> Below should be an RDEPENDS, no ?
>>>
>>> INIT: version 2.88 booting
>>> Starting udev
>>> udevd[59]: starting version 182
>>> /etc/rcS.d/S04udev: line 108: udevadm: command not found
>>> /etc/rcS.d/S04udev: line 113: udevadm: command not found
>>> /etc/rcS.d/S04udev: line 114: udevadm: command not found
>>
>> That depends (ha ha) on what the udevadm call in question is actually
>> doing.  If udev is so badly broken without it as to be unusable then
>> yes, it should be an RDEPENDS.  If udev will still work without then
>> RRECOMMENDS is appropriate and the initscript should be tweaked to deal
>> with it.
>>
>> p.
>>
>>
>
>
> SNIP
> -- 
>    udevadm control --env=STARTUP=1
>    if [ "$not_first_boot" != "" ];then
>            udevadm trigger --action=add --subsystem-nomatch=tty 
> --subsystem-nomatch=mem --subsystem-nomatch=vc 
> --subsystem-nomatch=vtconsole --subsystem-nomatch=misc 
> --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus 
> --subsystem-nomatch=graphics        --subsystem-nomatch=backlight 
> --subsystem-nomatch=video4linux  --subsystem-nomatch=platform
>            (udevadm settle --timeout=10; udevadm control --env=STARTUP=)&
>    else
>            udevadm trigger --action=add
>            udevadm settle
>    fi
> -- 
> SNIP
>
> Does this classify as essential ?
>
> If essential, we either need to move udev-utils to RDEPENDS.
> If not essential, fix the script to detect if udevadm is available.
>
> Br,
> David

Hi All,

I think it's essential.
Without 'udevadm trigger --action=add', the system start-up process may 
have some problem. I can recall that once I removed this line from the 
init scripts in my live image, the image could not boot up correctly.

I think this patch is reasonable and I'd like to acknowledge it.

Best Regards,
Chen Qi

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Saul Wold - June 5, 2014, 11:47 p.m.
On 06/02/2014 11:58 PM, ChenQi wrote:
> On 02/03/2014 10:01 PM, David Nyström wrote:
>> On mån  3 feb 2014 14:43:53, Phil Blundell wrote:
>>> On Mon, 2014-02-03 at 13:58 +0100, David Nyström wrote:
>>>> An intended fix for below error message with core-image-lsb,
>>>> Sending this as an RFC since I dont really know what constitutes
>>>> a RRECOMMENDS vs. RDEPENDS.
>>>> Is this clearly defined somewhere ?
>>>> Below should be an RDEPENDS, no ?
>>>>
>>>> INIT: version 2.88 booting
>>>> Starting udev
>>>> udevd[59]: starting version 182
>>>> /etc/rcS.d/S04udev: line 108: udevadm: command not found
>>>> /etc/rcS.d/S04udev: line 113: udevadm: command not found
>>>> /etc/rcS.d/S04udev: line 114: udevadm: command not found
>>>
>>> That depends (ha ha) on what the udevadm call in question is actually
>>> doing.  If udev is so badly broken without it as to be unusable then
>>> yes, it should be an RDEPENDS.  If udev will still work without then
>>> RRECOMMENDS is appropriate and the initscript should be tweaked to deal
>>> with it.
>>>
>>> p.
>>>
>>>
>>
>>
>> SNIP
>> --
>>    udevadm control --env=STARTUP=1
>>    if [ "$not_first_boot" != "" ];then
>>            udevadm trigger --action=add --subsystem-nomatch=tty
>> --subsystem-nomatch=mem --subsystem-nomatch=vc
>> --subsystem-nomatch=vtconsole --subsystem-nomatch=misc
>> --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus
>> --subsystem-nomatch=graphics        --subsystem-nomatch=backlight
>> --subsystem-nomatch=video4linux  --subsystem-nomatch=platform
>>            (udevadm settle --timeout=10; udevadm control --env=STARTUP=)&
>>    else
>>            udevadm trigger --action=add
>>            udevadm settle
>>    fi
>> --
>> SNIP
>>
>> Does this classify as essential ?
>>
>> If essential, we either need to move udev-utils to RDEPENDS.
>> If not essential, fix the script to detect if udevadm is available.
>>
>> Br,
>> David
>
> Hi All,
>
> I think it's essential.
> Without 'udevadm trigger --action=add', the system start-up process may
> have some problem. I can recall that once I removed this line from the
> init scripts in my live image, the image could not boot up correctly.
>
> I think this patch is reasonable and I'd like to acknowledge it.
>

If it's that essential, then we should incude udevadm in the udev 
package directly and not have a 1 file package for udev-utils at all.

v2 patch welcome

Sau!

> Best Regards,
> Chen Qi
>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
Koen Kooi - June 6, 2014, 9:34 a.m.
Op 3 jun. 2014, om 08:58 heeft ChenQi <Qi.Chen@windriver.com> het volgende geschreven:

> On 02/03/2014 10:01 PM, David Nyström wrote:
>> On mån  3 feb 2014 14:43:53, Phil Blundell wrote:
>>> On Mon, 2014-02-03 at 13:58 +0100, David Nyström wrote:
>>>> An intended fix for below error message with core-image-lsb,
>>>> Sending this as an RFC since I dont really know what constitutes
>>>> a RRECOMMENDS vs. RDEPENDS.
>>>> Is this clearly defined somewhere ?
>>>> Below should be an RDEPENDS, no ?
>>>> 
>>>> INIT: version 2.88 booting
>>>> Starting udev
>>>> udevd[59]: starting version 182
>>>> /etc/rcS.d/S04udev: line 108: udevadm: command not found
>>>> /etc/rcS.d/S04udev: line 113: udevadm: command not found
>>>> /etc/rcS.d/S04udev: line 114: udevadm: command not found
>>> 
>>> That depends (ha ha) on what the udevadm call in question is actually
>>> doing.  If udev is so badly broken without it as to be unusable then
>>> yes, it should be an RDEPENDS.  If udev will still work without then
>>> RRECOMMENDS is appropriate and the initscript should be tweaked to deal
>>> with it.
>>> 
>>> p.
>>> 
>>> 
>> 
>> 
>> SNIP
>> -- 
>>   udevadm control --env=STARTUP=1
>>   if [ "$not_first_boot" != "" ];then
>>           udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus --subsystem-nomatch=graphics     --subsystem-nomatch=backlight --subsystem-nomatch=video4linux  --subsystem-nomatch=platform
>>           (udevadm settle --timeout=10; udevadm control --env=STARTUP=)&
>>   else
>>           udevadm trigger --action=add
>>           udevadm settle
>>   fi
>> -- 
>> SNIP
>> 
>> Does this classify as essential ?
>> 
>> If essential, we either need to move udev-utils to RDEPENDS.
>> If not essential, fix the script to detect if udevadm is available.
>> 
>> Br,
>> David
> 
> Hi All,
> 
> I think it's essential.
> Without 'udevadm trigger --action=add', the system start-up process may have some problem. I can recall that once I removed this line from the init scripts in my live image, the image could not boot up correctly.

This only happens in sysv mode.

> I think this patch is reasonable and I'd like to acknowledge it.

Only for sysv based systemd, for systemd based systems it isn't needed. So please confine your change to sysv.

Patch

diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
index 1b22525..b22c1c1 100644
--- a/meta/recipes-core/udev/udev.inc
+++ b/meta/recipes-core/udev/udev.inc
@@ -58,7 +58,8 @@  INITSCRIPT_NAME_udev-cache = "udev-cache"
 INITSCRIPT_PARAMS_udev-cache = "start 36 S ."
 
 FILES_${PN} += "${libexecdir} ${libdir}/ConsoleKit ${nonarch_base_libdir}/udev"
-RRECOMMENDS_${PN} += "udev-utils udev-cache"
+RRECOMMENDS_${PN} += "udev-cache"
+RDEPENDS_${PN} += "udev-utils"
 
 FILES_${PN}-dbg += "${libexecdir}/.debug"
 FILES_${PN}-dbg += "${base_libdir}/udev/.debug/"