[PATCH 3/4] udev: Change hard coded /usr/lib to support multilib

[PATCH 3/4] udev: Change hard coded /usr/lib to support multilib

[Dongxiao Xu]

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
---
 meta/recipes-core/udev/udev-164/makefile.patch |   14 ++++++++++++++
 meta/recipes-core/udev/udev-new.inc            |    1 +
 meta/recipes-core/udev/udev_145.bb             |    2 +-
 3 files changed, 16 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..1fb0307
--- /dev/null
+++ b/meta/recipes-core/udev/udev-164/makefile.patch
@@ -0,0 +1,14 @@
+diff -ruN udev-164-orig/Makefile.am udev-164/Makefile.am
+--- udev-164-orig/Makefile.am	2011-07-11 16:10:26.000000000 +0800
++++ udev-164/Makefile.am	2011-07-11 16:11:14.000000000 +0800
+@@ -468,8 +468,8 @@
+ libexec_PROGRAMS += extras/udev-acl/udev-acl
+ 
+ udevacl-install-hook:
+-	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
+ 
+ INSTALL_EXEC_HOOKS += udevacl-install-hook
+ 
diff --git a/meta/recipes-core/udev/udev-new.inc b/meta/recipes-core/udev/udev-new.inc
index 4c4451f..b482a5a 100644
--- a/meta/recipes-core/udev/udev-new.inc
+++ b/meta/recipes-core/udev/udev-new.inc
@@ -16,6 +16,7 @@ RRECOMMENDS_${PN} += "udev-extraconf udev-cache usbutils-ids pciutils-ids"
 RDEPENDS_libudev = "${PN} (= ${EXTENDPKGV})"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/utils/kernel/hotplug/udev-${PV}.tar.gz \
+           file://makefile.patch \
            file://run.rules \
            file://udev.rules \
            file://devfs-udev.rules \
diff --git a/meta/recipes-core/udev/udev_145.bb b/meta/recipes-core/udev/udev_145.bb
index becef04..e13e0a5 100644
--- a/meta/recipes-core/udev/udev_145.bb
+++ b/meta/recipes-core/udev/udev_145.bb
@@ -1,6 +1,6 @@
 RPROVIDES_${PN} = "hotplug"
 
-PR = "r11"
+PR = "r12"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/utils/kernel/hotplug/udev-${PV}.tar.gz \
            file://enable-gudev.patch;patch=1 \
-- 
1.7.1

[PATCH 0/4][PULL] Resend: multilib: change hard coded /usr/lib path.

[Dongxiao Xu]

Hi Richard,

(Please ignore the previous pull request which doesn't contain the latest code.)

This pull request fixes some hard coded /usr/lib path in recipes within
minimal image. Please help to review and pull.

Thanks,
Dongxiao

The following changes since commit fa4bcfdb73167f8159b88e5a4d711c0d37627a70:

  bb-matrix: correct BB and PM number canonicalization (2011-07-14 22:23:09 +0100)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib dxu4/multilib
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/multilib

Dongxiao Xu (3):
  xcb-proto: add multilib support.
  pciutils: Change the hardcoded /usr/lib to support multilib.
  udev: Change hard coded /usr/lib to support multilib

Yu Ke (1):
  perl: revise the RRECOMMENDS_perl-modules for multilib case

 .../pciutils/pciutils-3.1.7/makefile.patch         |   14 ++++++++++++
 meta/recipes-bsp/pciutils/pciutils_3.1.7.bb        |    5 ++-
 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 +-
 meta/recipes-devtools/perl/perl_5.12.3.bb          |    2 +-
 .../xcb/xcb-proto-1.6/aclocal.patch                |   22 ++++++++++++++++++++
 meta/recipes-graphics/xcb/xcb-proto.inc            |    3 +-
 meta/recipes-graphics/xcb/xcb-proto_1.6.bb         |    2 +-
 meta/recipes-graphics/xcb/xcb-proto_git.bb         |    2 +-
 10 files changed, 62 insertions(+), 7 deletions(-)
 create mode 100644 meta/recipes-bsp/pciutils/pciutils-3.1.7/makefile.patch
 create mode 100644 meta/recipes-core/udev/udev-164/makefile.patch
 create mode 100644 meta/recipes-graphics/xcb/xcb-proto-1.6/aclocal.patch

[PATCH 1/4] xcb-proto: add multilib support.

[Dongxiao Xu]

There is hardcode of /usr/lib dir for some python files.
Fix it to support multilib.

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
---
 .../xcb/xcb-proto-1.6/aclocal.patch                |   22 ++++++++++++++++++++
 meta/recipes-graphics/xcb/xcb-proto.inc            |    3 +-
 meta/recipes-graphics/xcb/xcb-proto_1.6.bb         |    2 +-
 meta/recipes-graphics/xcb/xcb-proto_git.bb         |    2 +-
 4 files changed, 26 insertions(+), 3 deletions(-)
 create mode 100644 meta/recipes-graphics/xcb/xcb-proto-1.6/aclocal.patch

diff --git a/meta/recipes-graphics/xcb/xcb-proto-1.6/aclocal.patch b/meta/recipes-graphics/xcb/xcb-proto-1.6/aclocal.patch
new file mode 100644
index 0000000..124f146
--- /dev/null
+++ b/meta/recipes-graphics/xcb/xcb-proto-1.6/aclocal.patch
@@ -0,0 +1,22 @@
+Upstream-Status: Inappropriate [configuration]
+
+diff -ruN xcb-proto-1.6-orig/aclocal.m4 xcb-proto-1.6/aclocal.m4
+--- xcb-proto-1.6-orig/aclocal.m4	2011-07-08 15:45:33.000000000 +0800
++++ xcb-proto-1.6/aclocal.m4	2011-07-08 15:48:19.000000000 +0800
+@@ -518,6 +518,7 @@
+   dnl general consensus is that you shouldn't need this ability.
+ 
+   AC_SUBST([PYTHON_PREFIX], ['${prefix}'])
++  AC_SUBST([PYTHON_LIB_PREFIX], ['${libdir}'])
+   AC_SUBST([PYTHON_EXEC_PREFIX], ['${exec_prefix}'])
+ 
+   dnl At times (like when building shared libraries) you may want
+@@ -546,7 +547,7 @@
+        am_py_prefix=$prefix
+      fi
+      am_cv_python_pythondir=`$PYTHON -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='$am_py_prefix'))" 2>/dev/null ||
+-     echo "$PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages"`
++     echo "$PYTHON_LIB_PREFIX/python$PYTHON_VERSION/site-packages"`
+      case $am_cv_python_pythondir in
+      $am_py_prefix*)
+        am__strip_prefix=`echo "$am_py_prefix" | sed 's|.|.|g'`
diff --git a/meta/recipes-graphics/xcb/xcb-proto.inc b/meta/recipes-graphics/xcb/xcb-proto.inc
index cd7e115..76688c9 100644
--- a/meta/recipes-graphics/xcb/xcb-proto.inc
+++ b/meta/recipes-graphics/xcb/xcb-proto.inc
@@ -9,7 +9,8 @@ BUGTRACKER = "https://bugs.freedesktop.org/enter_bug.cgi?product=XCB"
 SECTION = "x11/libs"
 LICENSE = "MIT-X"
 
-SRC_URI = "http://xcb.freedesktop.org/dist/xcb-proto-${PV}.tar.bz2"
+SRC_URI = "http://xcb.freedesktop.org/dist/xcb-proto-${PV}.tar.bz2 \
+           file://aclocal.patch"
 
 inherit autotools pkgconfig
 
diff --git a/meta/recipes-graphics/xcb/xcb-proto_1.6.bb b/meta/recipes-graphics/xcb/xcb-proto_1.6.bb
index 3133977..1868f1a 100644
--- a/meta/recipes-graphics/xcb/xcb-proto_1.6.bb
+++ b/meta/recipes-graphics/xcb/xcb-proto_1.6.bb
@@ -4,7 +4,7 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d763b081cb10c223435b01e00dc0aba7 \
                     file://src/dri2.xml;beginline=2;endline=28;md5=f8763b13ff432e8597e0d610cf598e65"
 
-PR = "r1"
+PR = "r2"
 
 SRC_URI[md5sum] = "04313e1d914b44d0e457f6c494fc178b"
 SRC_URI[sha256sum] = "f52bc1159b12496f002404eb5793c01277b20c82cb72c5ff076d7b25da9b5ca2"
diff --git a/meta/recipes-graphics/xcb/xcb-proto_git.bb b/meta/recipes-graphics/xcb/xcb-proto_git.bb
index 01a7d91..2711213 100644
--- a/meta/recipes-graphics/xcb/xcb-proto_git.bb
+++ b/meta/recipes-graphics/xcb/xcb-proto_git.bb
@@ -3,7 +3,7 @@ DEFAULT_PREFERENCE = "-1"
 include xcb-proto.inc
 SRCREV = "d81ca233e98be8fa59e8c90d262c0516944c5a66"
 PV = "1.2+gitr${SRCPV}"
-PR = "r1"
+PR = "r2"
 
 SRC_URI = "git://anongit.freedesktop.org/git/xcb/proto;protocol=git"
 S = "${WORKDIR}/git"
-- 
1.7.1

[PATCH 2/4] pciutils: Change the hardcoded /usr/lib to support multilib.

[Dongxiao Xu]

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
---
 .../pciutils/pciutils-3.1.7/makefile.patch         |   14 ++++++++++++++
 meta/recipes-bsp/pciutils/pciutils_3.1.7.bb        |    5 +++--
 2 files changed, 17 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-bsp/pciutils/pciutils-3.1.7/makefile.patch

diff --git a/meta/recipes-bsp/pciutils/pciutils-3.1.7/makefile.patch b/meta/recipes-bsp/pciutils/pciutils-3.1.7/makefile.patch
new file mode 100644
index 0000000..811aac8
--- /dev/null
+++ b/meta/recipes-bsp/pciutils/pciutils-3.1.7/makefile.patch
@@ -0,0 +1,14 @@
+Upstream-Status: Inappropriate [configuration]
+
+diff -ruN pciutils-3.1.7-orig/Makefile pciutils-3.1.7/Makefile
+--- pciutils-3.1.7-orig/Makefile	2011-07-11 14:41:59.000000000 +0800
++++ pciutils-3.1.7/Makefile	2011-07-11 14:42:31.000000000 +0800
+@@ -31,7 +31,7 @@
+ IDSDIR=$(SHAREDIR)
+ MANDIR:=$(shell if [ -d $(PREFIX)/share/man ] ; then echo $(PREFIX)/share/man ; else echo $(PREFIX)/man ; fi)
+ INCDIR=$(PREFIX)/include
+-LIBDIR=$(PREFIX)/lib
++LIBDIR=$(libdir)
+ PKGCFDIR=$(LIBDIR)/pkgconfig
+ 
+ # Commands
diff --git a/meta/recipes-bsp/pciutils/pciutils_3.1.7.bb b/meta/recipes-bsp/pciutils/pciutils_3.1.7.bb
index 4e6d4e1..b48aaf0 100644
--- a/meta/recipes-bsp/pciutils/pciutils_3.1.7.bb
+++ b/meta/recipes-bsp/pciutils/pciutils_3.1.7.bb
@@ -9,13 +9,14 @@ LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
 DEPENDS = "zlib"
 RDEPENDS_${PN} = "${PN}-ids"
-PR = "r1"
+PR = "r2"
 
 SRC_URI = "${KERNELORG_MIRROR}/software/utils/pciutils/pciutils-${PV}.tar.bz2 \
            file://configure.patch \
            file://pcimodules-pciutils.diff \
            file://lib-build-fix.patch \
-           file://guess-fix.patch"
+           file://guess-fix.patch \
+           file://makefile.patch"
 
 SRC_URI[md5sum] = "35222edb86b50a6641352c66fe829b2e"
 SRC_URI[sha256sum] = "d8fe23b6966c1abf29b3b38b08b0cf33f731cd6e6a89d9b8d2b8d5e982c3f544"
-- 
1.7.1

[PATCH 3/4] udev: Change hard coded /usr/lib to support multilib

[Dongxiao Xu]

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]
+
+diff -ruN udev-164-orig/Makefile.am udev-164/Makefile.am
+--- udev-164-orig/Makefile.am	2011-07-11 16:10:26.000000000 +0800
++++ udev-164/Makefile.am	2011-07-11 16:11:14.000000000 +0800
+@@ -468,8 +468,8 @@
+ libexec_PROGRAMS += extras/udev-acl/udev-acl
+ 
+ udevacl-install-hook:
+-	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
+ 
+ INSTALL_EXEC_HOOKS += udevacl-install-hook
+ 
diff --git a/meta/recipes-core/udev/udev-new.inc b/meta/recipes-core/udev/udev-new.inc
index 4c4451f..b482a5a 100644
--- a/meta/recipes-core/udev/udev-new.inc
+++ b/meta/recipes-core/udev/udev-new.inc
@@ -16,6 +16,7 @@ RRECOMMENDS_${PN} += "udev-extraconf udev-cache usbutils-ids pciutils-ids"
 RDEPENDS_libudev = "${PN} (= ${EXTENDPKGV})"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/utils/kernel/hotplug/udev-${PV}.tar.gz \
+           file://makefile.patch \
            file://run.rules \
            file://udev.rules \
            file://devfs-udev.rules \
diff --git a/meta/recipes-core/udev/udev_164.bb b/meta/recipes-core/udev/udev_164.bb
index 567e62e..518d37a 100644
--- a/meta/recipes-core/udev/udev_164.bb
+++ b/meta/recipes-core/udev/udev_164.bb
@@ -1,6 +1,6 @@
 include udev-new.inc
 
-PR = "r3"
+PR = "r4"
 
 SRC_URI[md5sum] = "fddac2d54761ea34865af9467377ca9f"
 SRC_URI[sha256sum] = "c12e66280b5e1465f6587a8cfa47d7405c4caa7e52ce5dd13478d04f6ec05e5c"
-- 
1.7.1

[PATCH 4/4] perl: revise the RRECOMMENDS_perl-modules for multilib case

[Dongxiao Xu]

From: Yu Ke <ke.yu@intel.com>

current RRECOMMENDS_perl-modules replace the hardcode "perl-dbg",
"perl-misc" etc. which does not work in multilib case. Instead, it
should replace the "lib64-perl-dbg", "lib-64-perl-misc". without
doing this, current code will produce RRECOMMENDS=lib64-lib64-xxx etc

This patch revise the code to fix this issue

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Xu Dongxiao <dongxiao.xu@intel.com>
---
 meta/recipes-devtools/perl/perl_5.12.3.bb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-devtools/perl/perl_5.12.3.bb b/meta/recipes-devtools/perl/perl_5.12.3.bb
index c75a532..4b6b5a7 100644
--- a/meta/recipes-devtools/perl/perl_5.12.3.bb
+++ b/meta/recipes-devtools/perl/perl_5.12.3.bb
@@ -282,7 +282,7 @@ FILES_perl-module-unicore += "${libdir}/perl/${PV}/unicore"
 # packages (actually the non modules packages and not created too)
 ALLOW_EMPTY_perl-modules = "1"
 PACKAGES_append = " perl-modules "
-RRECOMMENDS_perl-modules = "${@bb.data.getVar('PACKAGES', d, 1).replace('perl-modules ', '').replace('perl-dbg ', '').replace('perl-misc ', '').replace('perl-dev ', '').replace('perl-pod ', '').replace('perl-doc ', '')}"
+RRECOMMENDS_perl-modules = "${@bb.data.getVar('PACKAGES', d, 1).replace('${PN}-modules ', '').replace('${PN}-dbg ', '').replace('${PN}-misc ', '').replace('${PN}-dev ', '').replace('${PN}-pod ', '').replace('${PN}-doc ', '')}"
 
 python populate_packages_prepend () {
         libdir = bb.data.expand('${libdir}/perl/${PV}', d)
-- 
1.7.1

Re: [PATCH 3/4] udev: Change hard coded /usr/lib to support multilib

[Koen Kooi]

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?

Re: [PATCH 3/4] udev: Change hard coded /usr/lib to support multilib

[Koen Kooi]

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?

regards,

Koen

Re: [PATCH 3/4] udev: Change hard coded /usr/lib to support multilib

[Koen Kooi]

Op 18 jul 2011, om 14:32 heeft Koen Kooi het volgende geschreven:

> 
> 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?


Some more:

14:33 < kay> koen: yeah, libdir can never be used for any "app private dir"
14:34 < kay> koen: /lib/<pkgname>/ /usr/lib/<pkgname>/ is app-priv-dir and never libdir
14:34 < kay> koen: but you should not use udev-acl anyway, i guess :)
14:34 < koen> that's another thing :)
14:34 < kay> koen: i disabled it by default now
14:34 < kay> all in sysyemd
14:34 < koen> the patch was for 164, I'm at 172 now without acl
14:35 < koen> we're adding multilib support to our buildsystem and we're having trouble judging when to use ${libdir} or ${prefix}/lib in some cases
14:35 < koen> I expected udev to be fairly sane by now, hence the question
14:35 < kay> koen: libdir only for .so, never anything else

Re: [PATCH 3/4] udev: Change hard coded /usr/lib to support multilib

[Mark Hatle]

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"

--Mark

> regards,
> 
> Koen
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 3/4] udev: Change hard coded /usr/lib to support multilib

[Mark Hatle]

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

Re: [PATCH 3/4] udev: Change hard coded /usr/lib to support multilib

[Xu, Dongxiao]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Mark Hatle
> Sent: Monday, July 18, 2011 11:30 PM
> To: openembedded-core@lists.openembedded.org
> 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 <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.)

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?

Thanks,
Dongxiao

> 
> --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
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 3/4] udev: Change hard coded /usr/lib to support multilib

[Koen Kooi]

Op 19 jul 2011, om 02:30 heeft Xu, Dongxiao het volgende geschreven:

>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Monday, July 18, 2011 11:30 PM
>> To: openembedded-core@lists.openembedded.org
>> 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 <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.)
> 
> 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?

That's how I read it, but again, I'm no (multi)lib expert :)

Re: [PATCH 3/4] udev: Change hard coded /usr/lib to support multilib

[Richard Purdie]

On Tue, 2011-07-19 at 09:41 +0200, Koen Kooi wrote:
> Op 19 jul 2011, om 02:30 heeft Xu, Dongxiao het volgende geschreven:
> 
> >> -----Original Message-----
> >> From: openembedded-core-bounces@lists.openembedded.org
> >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> >> Mark Hatle
> >> Sent: Monday, July 18, 2011 11:30 PM
> >> To: openembedded-core@lists.openembedded.org
> >> 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 <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.)
> > 
> > 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?
> 
> That's how I read it, but again, I'm no (multi)lib expert :)

Correct.

I would argue that architecture independent data files should really be
in $datadir and that configuration files should be in $sysconfdir.
$libdir should be used for architecture specific library files (likewise
libexecdir for executables). Not everyone is doing this sanely though. I
can understand the rpm issue from a history perspective but consolekit
doing it is plain wrong :/.

Architecture independent executables in the form of scripts are an
interesting case I guess.

Cheers,

Richard

Re: [PATCH 0/4][PULL] Resend: multilib: change hard coded /usr/lib path.

[Saul Wold]

On 07/17/2011 11:13 PM, Dongxiao Xu wrote:
> Hi Richard,
>
> (Please ignore the previous pull request which doesn't contain the latest code.)
>
> This pull request fixes some hard coded /usr/lib path in recipes within
> minimal image. Please help to review and pull.
>
> Thanks,
> Dongxiao
>
> The following changes since commit fa4bcfdb73167f8159b88e5a4d711c0d37627a70:
>
>    bb-matrix: correct BB and PM number canonicalization (2011-07-14 22:23:09 +0100)
>
> are available in the git repository at:
>    git://git.pokylinux.org/poky-contrib dxu4/multilib
>    http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dxu4/multilib
>
> Dongxiao Xu (3):
>    xcb-proto: add multilib support.
>    pciutils: Change the hardcoded /usr/lib to support multilib.
There two were merged into OE-Core

>    udev: Change hard coded /usr/lib to support multilib
There is some discussion about this one not being needed on the list.

>
> Yu Ke (1):
>    perl: revise the RRECOMMENDS_perl-modules for multilib case
This has been merged also,

Thanks to both of you.

Sau!


>
>   .../pciutils/pciutils-3.1.7/makefile.patch         |   14 ++++++++++++
>   meta/recipes-bsp/pciutils/pciutils_3.1.7.bb        |    5 ++-
>   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 +-
>   meta/recipes-devtools/perl/perl_5.12.3.bb          |    2 +-
>   .../xcb/xcb-proto-1.6/aclocal.patch                |   22 ++++++++++++++++++++
>   meta/recipes-graphics/xcb/xcb-proto.inc            |    3 +-
>   meta/recipes-graphics/xcb/xcb-proto_1.6.bb         |    2 +-
>   meta/recipes-graphics/xcb/xcb-proto_git.bb         |    2 +-
>   10 files changed, 62 insertions(+), 7 deletions(-)
>   create mode 100644 meta/recipes-bsp/pciutils/pciutils-3.1.7/makefile.patch
>   create mode 100644 meta/recipes-core/udev/udev-164/makefile.patch
>   create mode 100644 meta/recipes-graphics/xcb/xcb-proto-1.6/aclocal.patch
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [PATCH 3/4] udev: Change hard coded /usr/lib to support multilib

[Khem Raj]

On 07/18/2011 05:30 PM, Xu, Dongxiao wrote:
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Monday, July 18, 2011 11:30 PM
>> To: openembedded-core@lists.openembedded.org
>> 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<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.)
>
> 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