On 07/18/2011 05:30 PM, Xu, Dongxiao wrote:
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Mark Hatle
Sent: Monday, July 18, 2011 11:30 PM
To: [email protected]
Subject: Re: [OE-core] [PATCH 3/4] udev: Change hard coded /usr/lib to support
multilib

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<[email protected]>
---
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.)

So for multilib system, we have /usr/lib32 and /usr/lib64 to contain only *.so 
files, while there is still /usr/lib directory which contains other types of 
files, right?

in ideal world /usr/lib could just be a symlink to default multilib


_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Reply via email to