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

[Otavio Salvador]

On Tue, Apr 9, 2013 at 12:49 PM, Mark Hatle <mark.hatle at windriver.com> wrote:
> 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!

This was my proposed fix when Ross asked me about it. I also did
comment on this in the bug and it seemed ignored.

Another thing, systemd's udevd will be named differently, as:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core/initrdscripts?id=1b99640481882d23dc3ded41d9f2aef906f77e67

--
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br