[OE-core] [PATCH v2] udev: Move udevd back to /sbin

Mark Hatle mark.hatle at windriver.com
Tue Apr 9 15:49:13 UTC 2013


On 4/9/13 10:07 AM, Richard Purdie wrote:
> On Tue, 2013-04-09 at 16:44 +0200, Koen Kooi wrote:
>> Op 9 apr. 2013, om 16:41 heeft Koen Kooi <koen at dominion.thruhere.net> het volgende geschreven:
>>
>>>
>>> Op 9 apr. 2013, om 16:36 heeft Otavio Salvador <otavio at ossystems.com.br> het volgende geschreven:
>>>
>>>> On Tue, Apr 9, 2013 at 9:35 AM, Richard Purdie
>>>> <richard.purdie at linuxfoundation.org> wrote:
>>>>> On Mon, 2013-04-08 at 19:29 +0300, Radu Moisan wrote:
>>>>>> Along with v182 upgrade udevd was moved to ${base_libdir}
>>>>>> making scripts like init-live.sh to fail in finding udevd
>>>>>>
>>>>>> Fixes [Yocto #4046]
>>>>>>
>>>>>> Signed-off-by: Radu Moisan <radu.moisan at intel.com>
>>>>>> ---
>>>>>> meta/recipes-core/udev/udev.inc    |    3 ++-
>>>>>> meta/recipes-core/udev/udev_182.bb |    2 +-
>>>>>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>>>>
>>>>> We needed a decision on this. I've rewritten the commit message and
>>>>> merged it. Most of the feedback was about the commit message, not the
>>>>> patch itself. There were also no better proposals for how we could
>>>>> actually fix the bugs we were seeing.
>>>>
>>>> If I read the thread right, it had two NACK's. So it wasn't a cosmetic
>>>> commit log issue.
>>>
>>> 4 replies to the patch:
>>>
>>> 1) me asking about the commit log
>>> 2) me NACK'ing the patch
>
> Without any constructive way of fixing the issues. As I've said,
> "fixing" the other scripts does not work. Nobody has proposed any
> reasonable realistic way of unbreaking the multilib support which worked
> prior to the udev upgrade. Nobody has actually taken the time to even
> understand what is breaking as far as I can tell.

Let me task a whack at this.  If the binary belongs in /usr/lib/udevd/ (or 
/lib/udevd/) then that tells me it's being treated as a libexecdir and not a 
"libdir".  So the 64-bit versions of udev should NOT be installing into 
/usr/lib64/...  (nor /usr/lib32/...)

If that is the case, and all multilibs end up in /usr/lib/udevd (or /lib/udevd) 
then the multilib system should continue to work as expected.

(Note, prefer /lib/udevd myself... but that is a separate issue.)

If this sounds reasonable, I can try to make the changes and test the multilib 
config.  But I am far from a systemd/udev expert!

--Mark

>>> 3) Otavio NACK'ing the ptch
>
> Again, not constructively. People saying "no" just because they dislike
> it doesn't really work.
>
>>> 4) RP mentioning other discussions
>>
>> And by the way, does anyone actually bother testing patches to important infrastructure like udev?
>>
>> [koen at rrMBP udev]$ git log --oneline -1
>> a866e1e udev: Move udevd back to /sbin
>>
>> [koen at rrMBP udev]$ git grep /lib/udev/udevd
>> udev/init:[ -x /lib/udev/udevd ] || exit 1
>> udev/init:    /lib/udev/udevd -d
>> udev/udev-cache:[ -x /lib/udev/udevd ] || exit 1
>>
>> So the patch broke the sysvinit script, congratulations!
>
> Patch screw up :(. This will get fixed shortly, sorry about that.
>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>





More information about the Openembedded-core mailing list