Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH v2] udev: Move udevd back to /sbin
Date: Tue, 9 Apr 2013 10:49:13 -0500	[thread overview]
Message-ID: <51643879.30605@windriver.com> (raw)
In-Reply-To: <1365520076.12407.88.camel@ted>

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@dominion.thruhere.net> het volgende geschreven:
>>
>>>
>>> Op 9 apr. 2013, om 16:36 heeft Otavio Salvador <otavio@ossystems.com.br> het volgende geschreven:
>>>
>>>> On Tue, Apr 9, 2013 at 9:35 AM, Richard Purdie
>>>> <richard.purdie@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@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@rrMBP udev]$ git log --oneline -1
>> a866e1e udev: Move udevd back to /sbin
>>
>> [koen@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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>




  reply	other threads:[~2013-04-09 16:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-08 16:29 [PATCH v2] udev: Move udevd back to /sbin Radu Moisan
2013-04-08 20:32 ` Koen Kooi
2013-04-08 20:40   ` Otavio Salvador
2013-04-08 21:17     ` Richard Purdie
2013-04-09 12:35 ` Richard Purdie
2013-04-09 14:36   ` Otavio Salvador
2013-04-09 14:41     ` Koen Kooi
2013-04-09 14:44       ` Koen Kooi
2013-04-09 15:07         ` Richard Purdie
2013-04-09 15:49           ` Mark Hatle [this message]
2013-04-09 16:31             ` Otavio Salvador
2013-04-09 16:28           ` Otavio Salvador

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51643879.30605@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox