From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 3/4] udev: Change hard coded /usr/lib to support multilib
Date: Mon, 18 Jul 2011 10:29:39 -0500 [thread overview]
Message-ID: <4E245163.4000809@windriver.com> (raw)
In-Reply-To: <4E245054.4000303@windriver.com>
Replying to myself.. sorry, I misunderstood the concern.. see below for a new
explanation..
On 7/18/11 10:25 AM, Mark Hatle wrote:
> On 7/18/11 7:32 AM, Koen Kooi wrote:
>>
>> Op 18 jul 2011, om 09:08 heeft Koen Kooi het volgende geschreven:
>>
>>>
>>> Op 18 jul 2011, om 08:13 heeft Dongxiao Xu het volgende geschreven:
>>>
>>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
>>>> ---
>>>> meta/recipes-core/udev/udev-164/makefile.patch | 16 ++++++++++++++++
>>>> meta/recipes-core/udev/udev-new.inc | 1 +
>>>> meta/recipes-core/udev/udev_164.bb | 2 +-
>>>> 3 files changed, 18 insertions(+), 1 deletions(-)
>>>> create mode 100644 meta/recipes-core/udev/udev-164/makefile.patch
>>>>
>>>> diff --git a/meta/recipes-core/udev/udev-164/makefile.patch b/meta/recipes-core/udev/udev-164/makefile.patch
>>>> new file mode 100644
>>>> index 0000000..c46ff4b
>>>> --- /dev/null
>>>> +++ b/meta/recipes-core/udev/udev-164/makefile.patch
>>>> @@ -0,0 +1,16 @@
>>>> +Upstream-Status: Inappropriate [configuration]
>>>
>>> Could you explain why it's inappropriate for upstream but why we do need it here?
>>
>> I asked the udev maintainer:
>>
>> 14:25 < koen> kay: the udev Makefile.am has 'ln -sf $(libexecdir)/udev-acl $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck', any reason for not using ${libdir} over ${prefix}/lib ?
>> 14:29 < kay> koen: libdir is /usr/lib64 here, can't use that
>>
>> So upstream is aware of multilib, but wants to put these scripts in a non-multilib dir. Since I don't have any experience with the fedora/opensuse way of multilib nor the new oe-core one, could you please explain why oe-core needs this patch, but fedora/opensuse don't?
>
> This is likely a problem with the multilib fix. "libexecdir" is often /usr/lib
> on many distribuions.. however as your other email mentioned.. setting it to
> /usr/lib64 is a mistake. It should be /usr/libexec or /usr/lib64. All of the
> associated multilib packages should work correctly and no conflicts introduced
> with this package (file contents should be identical.)
>
> It should be permissible for libexecdir to be changed in the configuration if
> someone really wants it to be. By default (in bitbake.conf) it is:
>
> export libexecdir = "${exec_prefix}/libexec"
> +- mkdir -p $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d
> +- ln -sf $(libexecdir)/udev-acl $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck
> ++ mkdir -p $(DESTDIR)$(libdir)/ConsoleKit/run-seat.d
> ++ ln -sf $(libexecdir)/udev-acl $(DESTDIR)$(libdir)/ConsoleKit/run-seat.d/udev-acl.ck
I see libexecdir CAN be changed.. so the above is already possible..
The part they had hard coded is "/usr/lib/ConsoleKit"... There is only one
location in the system for ConsoleKit configuration files/scripts.. and that is
distro specific. Assuming the oe based distributions use
$(PREFIX)/lib/ConsoleKit.. then the previous was correct.
The point being it doesn't matter if it's 32-bit, 64-bit or 24-bit... only one
ConsoleKit per system should exist. (There are potentially other files on the
system like this. I know a recent RPM patch went in that separated /usr/lib/rpm
and /usr/lib64/rpm.. this is also a similar mistake, I just haven't had time to
get a patch out to revert that chunk.)
--Mark
> --Mark
>
>> regards,
>>
>> Koen
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> 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:[~2011-07-18 15:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 6:13 [PATCH 0/4][PULL] Resend: multilib: change hard coded /usr/lib path Dongxiao Xu
2011-07-18 6:13 ` [PATCH 1/4] xcb-proto: add multilib support Dongxiao Xu
2011-07-18 6:13 ` [PATCH 2/4] pciutils: Change the hardcoded /usr/lib to support multilib Dongxiao Xu
2011-07-18 6:13 ` [PATCH 3/4] udev: Change hard coded " Dongxiao Xu
2011-07-18 7:08 ` Koen Kooi
2011-07-18 12:32 ` Koen Kooi
2011-07-18 12:37 ` Koen Kooi
2011-07-18 15:25 ` Mark Hatle
2011-07-18 15:29 ` Mark Hatle [this message]
2011-07-19 0:30 ` Xu, Dongxiao
2011-07-19 7:41 ` Koen Kooi
2011-07-19 17:12 ` Richard Purdie
2011-07-20 17:08 ` Khem Raj
2011-07-18 6:13 ` [PATCH 4/4] perl: revise the RRECOMMENDS_perl-modules for multilib case Dongxiao Xu
2011-07-20 17:01 ` [PATCH 0/4][PULL] Resend: multilib: change hard coded /usr/lib path Saul Wold
-- strict thread matches above, loose matches on Subject: below --
2011-07-18 6:01 [PATCH 0/4][PULL] " Dongxiao Xu
2011-07-18 6:01 ` [PATCH 3/4] udev: Change hard coded /usr/lib to support multilib Dongxiao Xu
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=4E245163.4000809@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.