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
>
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.