* [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes
2011-09-20 21:33 [PATCH 0/7] Fix a number of package installation related items Mark Hatle
@ 2011-09-20 21:33 ` Mark Hatle
2011-09-20 21:50 ` Richard Purdie
2011-09-20 21:33 ` [PATCH 2/7] multilib: install MULTILIB_IMAGE_INSTALL Mark Hatle
` (5 subsequent siblings)
6 siblings, 1 reply; 10+ messages in thread
From: Mark Hatle @ 2011-09-20 21:33 UTC (permalink / raw)
To: openembedded-core
From: Dongxiao Xu <dongxiao.xu@intel.com>
Currently MACHINE_ARCH deploy folder is unique in multilib system, thus
a lib32 version of rpm package will override a normal rpm package if its
PACKAGE_ARCH is ${MACHINE_ARCH}.
Take netbase as an example, which the PACKAGE_ARCH = MACHINE_ARCH. Both
the normal version of netbase package and the lib32 version are named as
"netbase-4.45-r1.qemux86_64.rpm" putting in tmp/deploy/rpm/qemux86-64
directory, so we need to differentiate them.
Here we define spedific MACHINE_virtclass-multilib-lib(xx) to override
the default MACHINE value, thus got different MACHINE_ARCH to fix this
issue.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
meta/classes/rootfs_rpm.bbclass | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 135ca75..56c1a85 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -218,6 +218,9 @@ python () {
default_tune = localdata.getVar("DEFAULTTUNE_virtclass-multilib-" + eext[1], False)
if default_tune:
localdata.setVar("DEFAULTTUNE", default_tune)
+ machine = localdata.getVar("MACHINE_virtclass-multilib-" + eext[1], False)
+ if machine:
+ localdata.setVar("MACHINE", machine)
ml_package_archs += localdata.getVar("PACKAGE_ARCHS", True) or ""
#bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1], localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs, d)
--
1.7.3.4
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes
2011-09-20 21:33 ` [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes Mark Hatle
@ 2011-09-20 21:50 ` Richard Purdie
2011-09-20 23:49 ` Xu, Dongxiao
0 siblings, 1 reply; 10+ messages in thread
From: Richard Purdie @ 2011-09-20 21:50 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2011-09-20 at 16:33 -0500, Mark Hatle wrote:
> From: Dongxiao Xu <dongxiao.xu@intel.com>
>
> Currently MACHINE_ARCH deploy folder is unique in multilib system, thus
> a lib32 version of rpm package will override a normal rpm package if its
> PACKAGE_ARCH is ${MACHINE_ARCH}.
>
> Take netbase as an example, which the PACKAGE_ARCH = MACHINE_ARCH. Both
> the normal version of netbase package and the lib32 version are named as
> "netbase-4.45-r1.qemux86_64.rpm" putting in tmp/deploy/rpm/qemux86-64
> directory, so we need to differentiate them.
>
> Here we define spedific MACHINE_virtclass-multilib-lib(xx) to override
> the default MACHINE value, thus got different MACHINE_ARCH to fix this
> issue.
We simply *cannot* do this and this patch cannot be merged. I thought
I'd explained this once but I will try and do so again.
The problem is MACHINE specific packages can have generic content. They
may have binaries, libraries or other things contained within them. Lets
assume we have a strange system which has files in /lib, /lib32
and /lib64. We need the following permutations:
qemux86 /lib
qemux86 /lib64
qemux86 /lib32
and these are not equal to:
qemux86_64 /lib
qemux86_64 /lib64
qemux86_64 /lib32
which may or may not have different contents or different optimisations
applied to the binaries/libraries contained within.
You are trying to take a shortcut here and cross link these two sets and
that doesn't scale to generic combinations.
Furthermore, MACHINE is meant to be consistent within a given build and
changing MACHINE for different multilibs will have all kinds of
unintended consequences (such as the cache file location changing for
different recipes).
Wasn't there an alternative proposal from Dongxiao that added MLPREFIX
to MACHINE_ARCH and resolved this issue that way instead? I know that
causes issues at the package management level but I think we're going to
have to run with that approach and resolve any issues it leads to...
Cheers,
Richard
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes
2011-09-20 21:50 ` Richard Purdie
@ 2011-09-20 23:49 ` Xu, Dongxiao
0 siblings, 0 replies; 10+ messages in thread
From: Xu, Dongxiao @ 2011-09-20 23:49 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Hi Richard and Mark,
> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Wednesday, September 21, 2011 5:50 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH
> for multilib recipes
>
> On Tue, 2011-09-20 at 16:33 -0500, Mark Hatle wrote:
> > From: Dongxiao Xu <dongxiao.xu@intel.com>
> >
> > Currently MACHINE_ARCH deploy folder is unique in multilib system,
> > thus a lib32 version of rpm package will override a normal rpm package
> > if its PACKAGE_ARCH is ${MACHINE_ARCH}.
> >
> > Take netbase as an example, which the PACKAGE_ARCH = MACHINE_ARCH.
> > Both the normal version of netbase package and the lib32 version are
> > named as "netbase-4.45-r1.qemux86_64.rpm" putting in
> > tmp/deploy/rpm/qemux86-64 directory, so we need to differentiate them.
> >
> > Here we define spedific MACHINE_virtclass-multilib-lib(xx) to override
> > the default MACHINE value, thus got different MACHINE_ARCH to fix this
> > issue.
>
> We simply *cannot* do this and this patch cannot be merged. I thought I'd
> explained this once but I will try and do so again.
>
> The problem is MACHINE specific packages can have generic content. They
> may have binaries, libraries or other things contained within them. Lets
> assume we have a strange system which has files in /lib, /lib32 and /lib64. We
> need the following permutations:
>
> qemux86 /lib
> qemux86 /lib64
> qemux86 /lib32
>
> and these are not equal to:
>
> qemux86_64 /lib
> qemux86_64 /lib64
> qemux86_64 /lib32
>
> which may or may not have different contents or different optimisations
> applied to the binaries/libraries contained within.
>
> You are trying to take a shortcut here and cross link these two sets and that
> doesn't scale to generic combinations.
>
> Furthermore, MACHINE is meant to be consistent within a given build and
> changing MACHINE for different multilibs will have all kinds of unintended
> consequences (such as the cache file location changing for different recipes).
>
> Wasn't there an alternative proposal from Dongxiao that added MLPREFIX to
> MACHINE_ARCH and resolved this issue that way instead? I know that causes
> issues at the package management level but I think we're going to have to run
> with that approach and resolve any issues it leads to...
I have an updated commit in http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dxu4/ml4&id=6b2ed895e25bf6d76cc362c87661fd66231c4b4a
You can cherry-pick that to your pull request.
Thanks,
Dongxiao
>
> Cheers,
>
> Richard
>
>
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 2/7] multilib: install MULTILIB_IMAGE_INSTALL
2011-09-20 21:33 [PATCH 0/7] Fix a number of package installation related items Mark Hatle
2011-09-20 21:33 ` [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes Mark Hatle
@ 2011-09-20 21:33 ` Mark Hatle
2011-09-20 21:33 ` [PATCH 3/7] Fix RPM dependencies Mark Hatle
` (4 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: Mark Hatle @ 2011-09-20 21:33 UTC (permalink / raw)
To: openembedded-core
From: Dongxiao Xu <dongxiao.xu@intel.com>
If user set MULTILIB_IMAGE_INSTALL, we need to install those multitlib
packages into the final image.
Also fix the logic in handling multilib prefix. For certain case like a
normal image contains several multilib libraries, the image recipe isn't
extended with MLPREFIX, therefore we need to enumerate the possible
multilib prefixes and compare them with package prefixes.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
meta/classes/package_rpm.bbclass | 42 +++++++++++++++++++++++++------------
meta/classes/rootfs_rpm.bbclass | 4 +++
2 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 9ef1acd..4605ec8 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -166,7 +166,7 @@ package_install_internal_rpm () {
local platform="${INSTALL_PLATFORM_RPM}"
local platform_extra="${INSTALL_PLATFORM_EXTRA_RPM}"
local confbase="${INSTALL_CONFBASE_RPM}"
- local package_to_install="${INSTALL_PACKAGES_NORMAL_RPM}"
+ local package_to_install="${INSTALL_PACKAGES_NORMAL_RPM} ${INSTALL_PACKAGES_MULTILIB_RPM}"
local package_attemptonly="${INSTALL_PACKAGES_ATTEMPTONLY_RPM}"
local package_linguas="${INSTALL_PACKAGES_LINGUAS_RPM}"
local providename="${INSTALL_PROVIDENAME_RPM}"
@@ -210,10 +210,15 @@ package_install_internal_rpm () {
echo "Processing $pkg..."
archvar=base_archs
- ml_pkg=$(echo ${pkg} | sed "s,^${MLPREFIX}\(.*\),\1,")
- if [ "${ml_pkg}" != "${pkg}" ]; then
- archvar=ml_archs
- fi
+ ml_prefix=`echo ${pkg} | cut -d'-' -f1`
+ ml_pkg=$pkg
+ for i in ${MULTILIB_PREFIX_LIST} ; do
+ if [ ${ml_prefix} == ${i} ]; then
+ ml_pkg=$(echo ${pkg} | sed "s,^${ml_prefix}-\(.*\),\1,")
+ archvar=ml_archs
+ break
+ fi
+ done
pkg_name=$(resolve_package_rpm ${confbase}-${archvar}.conf ${ml_pkg})
if [ -z "$pkg_name" ]; then
@@ -224,16 +229,20 @@ package_install_internal_rpm () {
done
fi
fi
-
if [ ! -z "${package_to_install}" ]; then
for pkg in ${package_to_install} ; do
echo "Processing $pkg..."
archvar=base_archs
- ml_pkg=$(echo ${pkg} | sed "s,^${MLPREFIX}\(.*\),\1,")
- if [ "${ml_pkg}" != "${pkg}" ]; then
- archvar=ml_archs
- fi
+ ml_prefix=`echo ${pkg} | cut -d'-' -f1`
+ ml_pkg=$pkg
+ for i in ${MULTILIB_PREFIX_LIST} ; do
+ if [ ${ml_prefix} == ${i} ]; then
+ ml_pkg=$(echo ${pkg} | sed "s,^${ml_prefix}-\(.*\),\1,")
+ archvar=ml_archs
+ break
+ fi
+ done
pkg_name=$(resolve_package_rpm ${confbase}-${archvar}.conf ${ml_pkg})
if [ -z "$pkg_name" ]; then
@@ -258,10 +267,15 @@ package_install_internal_rpm () {
for pkg in ${package_attemptonly} ; do
echo "Processing $pkg..."
archvar=base_archs
- ml_pkg=$(echo ${pkg} | sed "s,^${MLPREFIX}\(.*\),\1,")
- if [ "${ml_pkg}" != "${pkg}" ]; then
- archvar=ml_archs
- fi
+ ml_prefix=`echo ${pkg} | cut -d'-' -f1`
+ ml_pkg=$pkg
+ for i in ${MULTILIB_PREFIX_LIST} ; do
+ if [ ${ml_prefix} == ${i} ]; then
+ ml_pkg=$(echo ${pkg} | sed "s,^${ml_prefix}-\(.*\),\1,")
+ archvar=ml_archs
+ break
+ fi
+ done
pkg_name=$(resolve_package_rpm ${confbase}-${archvar}.conf ${ml_pkg})
if [ -z "$pkg_name" ]; then
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 56c1a85..ec58700 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -58,6 +58,7 @@ fakeroot rootfs_rpm_do_rootfs () {
export INSTALL_PLATFORM_RPM="${TARGET_ARCH}"
export INSTALL_CONFBASE_RPM="${RPMCONF_TARGET_BASE}"
export INSTALL_PACKAGES_NORMAL_RPM="${PACKAGE_INSTALL}"
+ export INSTALL_PACKAGES_MULTILIB_RPM="${MULTILIB_PACKAGE_INSTALL}"
export INSTALL_PACKAGES_ATTEMPTONLY_RPM="${PACKAGE_INSTALL_ATTEMPTONLY}"
export INSTALL_PACKAGES_LINGUAS_RPM="${LINGUAS_INSTALL}"
export INSTALL_PROVIDENAME_RPM=""
@@ -210,6 +211,7 @@ python () {
bb.data.setVar('RPM_POSTPROCESS_COMMANDS', '', d)
ml_package_archs = ""
+ ml_prefix_list = ""
multilibs = d.getVar('MULTILIBS', True) or ""
for ext in multilibs.split():
eext = ext.split(':')
@@ -222,6 +224,8 @@ python () {
if machine:
localdata.setVar("MACHINE", machine)
ml_package_archs += localdata.getVar("PACKAGE_ARCHS", True) or ""
+ ml_prefix_list += " " + eext[1]
#bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1], localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides))
bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs, d)
+ bb.data.setVar('MULTILIB_PREFIX_LIST', ml_prefix_list, d)
}
--
1.7.3.4
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH 3/7] Fix RPM dependencies
2011-09-20 21:33 [PATCH 0/7] Fix a number of package installation related items Mark Hatle
2011-09-20 21:33 ` [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes Mark Hatle
2011-09-20 21:33 ` [PATCH 2/7] multilib: install MULTILIB_IMAGE_INSTALL Mark Hatle
@ 2011-09-20 21:33 ` Mark Hatle
2011-09-20 21:33 ` [PATCH 4/7] Add a run-time dependency that eglibc support GNU_HASH Mark Hatle
` (3 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: Mark Hatle @ 2011-09-20 21:33 UTC (permalink / raw)
To: openembedded-core
When packaging for RPM, dependencies were not being properly added
to the packages. Only the "providing" dependencies were added due
to a typo.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
meta/classes/package_rpm.bbclass | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 4605ec8..d822b54 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -840,7 +840,7 @@ python do_package_rpm () {
os.chmod(outdepends, 0755)
# Poky / RPM Provides
- outprovides = workdir + "/" + srcname + ".requires"
+ outprovides = workdir + "/" + srcname + ".provides"
try:
from __builtin__ import file
--
1.7.3.4
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH 4/7] Add a run-time dependency that eglibc support GNU_HASH
2011-09-20 21:33 [PATCH 0/7] Fix a number of package installation related items Mark Hatle
` (2 preceding siblings ...)
2011-09-20 21:33 ` [PATCH 3/7] Fix RPM dependencies Mark Hatle
@ 2011-09-20 21:33 ` Mark Hatle
2011-09-20 21:33 ` [PATCH 5/7] Update python dependencies to be simply to "python" Mark Hatle
` (2 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: Mark Hatle @ 2011-09-20 21:33 UTC (permalink / raw)
To: openembedded-core
RPM checks to see if binaries require GNU_HASH, if they do it adds
an automatic dependency of "rtld(GNU_HASH)". We need to satisfy
this dependency, and we do it by providing rtld(GNU_HASH) in the
package(s) that provide a runtime-linker.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
meta/recipes-core/eglibc/eglibc-package.inc | 3 ++-
meta/recipes-core/eglibc/eglibc_2.12.bb | 2 +-
meta/recipes-core/eglibc/eglibc_2.13.bb | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc b/meta/recipes-core/eglibc/eglibc-package.inc
index 469e02d..519a49c 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -22,7 +22,8 @@ PKGSUFFIX_virtclass-nativesdk = "-nativesdk"
PACKAGES = "${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX} nscd${PKGSUFFIX} ldd${PKGSUFFIX} ${PN}-utils eglibc-extra-nss${PKGSUFFIX} eglibc-thread-db${PKGSUFFIX} ${PN}-pic ${PN}-dev ${PN}-doc libcidn${PKGSUFFIX} libmemusage${PKGSUFFIX} libsegfault${PKGSUFFIX} ${PN}-pcprofile libsotruss${PKGSUFFIX}"
-RPROVIDES_${PN} = "glibc${PKGSUFFIX}"
+# The ld.so in this eglibc supports the GNU_HASH
+RPROVIDES_${PN} = "glibc${PKGSUFFIX} rtld(GNU_HASH)"
RPROVIDES_${PN}-utils = "glibc${PKGSUFFIX}-utils"
RPROVIDES_${PN}-pic = "glibc${PKGSUFFIX}-pic"
RPROVIDES_${PN}-dev = "glibc${PKGSUFFIX}-dev"
diff --git a/meta/recipes-core/eglibc/eglibc_2.12.bb b/meta/recipes-core/eglibc/eglibc_2.12.bb
index a71c4d4..a9d208b 100644
--- a/meta/recipes-core/eglibc/eglibc_2.12.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.12.bb
@@ -1,7 +1,7 @@
require eglibc.inc
DEPENDS += "gperf-native"
-PR = "r23"
+PR = "r24"
SRCREV = "14158"
diff --git a/meta/recipes-core/eglibc/eglibc_2.13.bb b/meta/recipes-core/eglibc/eglibc_2.13.bb
index b2da697..b549496 100644
--- a/meta/recipes-core/eglibc/eglibc_2.13.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.13.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = "14157"
DEPENDS += "gperf-native"
-PR = "r14"
+PR = "r15"
PR_append = "+svnr${SRCPV}"
EGLIBC_BRANCH="eglibc-2_13"
--
1.7.3.4
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH 5/7] Update python dependencies to be simply to "python"
2011-09-20 21:33 [PATCH 0/7] Fix a number of package installation related items Mark Hatle
` (3 preceding siblings ...)
2011-09-20 21:33 ` [PATCH 4/7] Add a run-time dependency that eglibc support GNU_HASH Mark Hatle
@ 2011-09-20 21:33 ` Mark Hatle
2011-09-20 21:33 ` [PATCH 6/7] busybox: Enhance to add dynamic per-file provides Mark Hatle
2011-09-20 21:33 ` [PATCH 7/7] multilib_global.bbclass: Fix non-multilib package provides Mark Hatle
6 siblings, 0 replies; 10+ messages in thread
From: Mark Hatle @ 2011-09-20 21:33 UTC (permalink / raw)
To: openembedded-core
Previously python dependencies were of the format "python(abi) = ..."
This format is not yet supportable within OE, so revert to a form
we know we can handle.
Introduce a change to package.bbclass that ensures it will causes the
sstate-cache's "package" to invalidate. Since pythondeps changed, the
output of rpmdeps changes, which causes the per-file dependency
information to change.... thus we need to invalidate the cache!
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
meta/classes/package.bbclass | 6 ++++++
meta/recipes-devtools/rpm/rpm/pythondeps.sh | 16 ++++++++++++++++
meta/recipes-devtools/rpm/rpm_5.4.0.bb | 4 +++-
3 files changed, 25 insertions(+), 1 deletions(-)
create mode 100755 meta/recipes-devtools/rpm/rpm/pythondeps.sh
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 3f5c904..e581ae2 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1,3 +1,9 @@
+# Change the following version to cause sstate to invalidate the package
+# cache. This is useful if an item this class depends on changes in a
+# way that the output of this class changes. rpmdeps is a good example
+# as any change to rpmdeps requires this to be rerun.
+PACKAGE_BBCLASS_VERSION = "r1"
+
#
# Packaging process
#
diff --git a/meta/recipes-devtools/rpm/rpm/pythondeps.sh b/meta/recipes-devtools/rpm/rpm/pythondeps.sh
new file mode 100755
index 0000000..083b174
--- /dev/null
+++ b/meta/recipes-devtools/rpm/rpm/pythondeps.sh
@@ -0,0 +1,16 @@
+#!/bin/sh
+
+[ $# -ge 1 ] || {
+ cat > /dev/null
+ exit 0
+}
+
+case $1 in
+-R|--requires)
+ shift
+ grep "/usr/\(lib[^/]*\|share\)/python[^/]*/" >/dev/null && echo "python"
+ exit 0
+ ;;
+esac
+
+exit 0
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.0.bb b/meta/recipes-devtools/rpm/rpm_5.4.0.bb
index b805f7d..a7b360d 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.0.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.0.bb
@@ -45,7 +45,7 @@ LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1"
DEPENDS = "bzip2 zlib db openssl elfutils expat libpcre attr acl popt ${extrarpmdeps}"
extrarpmdeps = "python perl"
extrarpmdeps_virtclass-native = ""
-PR = "r20"
+PR = "r21"
# rpm2cpio is a shell script, which is part of the rpm src.rpm. It is needed
# in order to extract the distribution SRPM into a format we can extract...
@@ -63,6 +63,7 @@ SRC_URI = "http://www.rpm5.org/files/rpm/rpm-5.4/rpm-5.4.0-0.20101229.src.rpm;ex
file://rpm-fileclass.patch \
file://rpm-canonarch.patch \
file://rpm-no-loopmsg.patch \
+ file://pythondeps.sh \
"
# file://rpm-autoconf.patch \
@@ -352,6 +353,7 @@ do_install_append() {
# Enable Debian style arbitrary tags...
sed -i -e 's,%_arbitrary_tags[^_].*,%_arbitrary_tags %{_arbitrary_tags_debian},' ${D}/${libdir}/rpm/macros
+ install -m 0755 ${WORKDIR}/pythondeps.sh ${D}/${libdir}/rpm/pythondeps.sh
install -m 0755 ${WORKDIR}/perfile_rpmdeps.sh ${D}/${libdir}/rpm/perfile_rpmdeps.sh
# Remove unpackaged files (based on list in rpm.spec)
--
1.7.3.4
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH 6/7] busybox: Enhance to add dynamic per-file provides
2011-09-20 21:33 [PATCH 0/7] Fix a number of package installation related items Mark Hatle
` (4 preceding siblings ...)
2011-09-20 21:33 ` [PATCH 5/7] Update python dependencies to be simply to "python" Mark Hatle
@ 2011-09-20 21:33 ` Mark Hatle
2011-09-20 21:33 ` [PATCH 7/7] multilib_global.bbclass: Fix non-multilib package provides Mark Hatle
6 siblings, 0 replies; 10+ messages in thread
From: Mark Hatle @ 2011-09-20 21:33 UTC (permalink / raw)
To: openembedded-core
When using the RPM package backend, we need a full list of per-file
provides (and requires). The busybox package provides a number of
command line utilities, such as /usr/bin/env. However, because
the utilities are created at post install time via scripting the
provide of each of the links was never made. So any programs,
such as python, that require /usr/bin/env were unable to resolve
the dependency and failed.
This change only affects packaging backends that use per-file
dependency data. Currently RPM is the only packaging backend
with this ability.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
meta/recipes-core/busybox/busybox.inc | 32 +++++++++++++++++++++++++++
meta/recipes-core/busybox/busybox_1.18.5.bb | 2 +-
2 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
index 3f93358..acd635b 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -205,6 +205,38 @@ do_install () {
install -m 0644 ${S}/busybox.links ${D}${sysconfdir}
}
+python package_do_filedeps_append () {
+ # We need to load the full set of busybox provides from the /etc/busybox.links
+ # The pkg_postinst_ is what creates the actual links
+
+ pkg = d.getVar('PN', True)
+ f_busybox = "/bin/busybox"
+ f_busybox_links = "/etc/busybox.links"
+
+ requires_files = []
+ provides_files = []
+
+ # Load/backup original set
+ filerprovides = d.getVar('FILERPROVIDES_%s_%s' % (f_busybox, pkg), True) or ""
+
+ dep_pipe = os.popen('sed -e "s,^,Provides: ," %s/%s%s' % (pkgdest, pkg, f_busybox_links))
+
+ process_deps(dep_pipe, pkg, "%s/%s%s" % (pkgdest, pkg, f_busybox), provides_files, requires_files)
+
+ # Add the new set
+ filerprovides += d.getVar('FILERPROVIDES_%s_%s' % (f_busybox, pkg), True) or ""
+
+ # Make sure there is an entry for this item in the FILERPROVIDESFLIST...
+ filerprovidesflist = (d.getVar('FILERPROVIDESFLIST_%s' % pkg, True) or "").split()
+ for file in provides_files:
+ if file not in filerprovidesflist:
+ filerprovidesflist.append(file)
+ d.setVar('FILERPROVIDESFLIST_%s' % pkg, " ".join(filerprovidesflist))
+
+ # Store the new provides
+ d.setVar('FILERPROVIDES_%s_%s' % (f_busybox, pkg), filerprovides)
+}
+
pkg_postinst_${PN} () {
# If we are not making an image we create links for the utilities that doesn't exist
# so the update-alternatives script will get the utilities it needs
diff --git a/meta/recipes-core/busybox/busybox_1.18.5.bb b/meta/recipes-core/busybox/busybox_1.18.5.bb
index c0dc1d4..bdafb31 100644
--- a/meta/recipes-core/busybox/busybox_1.18.5.bb
+++ b/meta/recipes-core/busybox/busybox_1.18.5.bb
@@ -1,5 +1,5 @@
require busybox.inc
-PR = "r0"
+PR = "r1"
SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://udhcpscript.patch \
--
1.7.3.4
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH 7/7] multilib_global.bbclass: Fix non-multilib package provides
2011-09-20 21:33 [PATCH 0/7] Fix a number of package installation related items Mark Hatle
` (5 preceding siblings ...)
2011-09-20 21:33 ` [PATCH 6/7] busybox: Enhance to add dynamic per-file provides Mark Hatle
@ 2011-09-20 21:33 ` Mark Hatle
6 siblings, 0 replies; 10+ messages in thread
From: Mark Hatle @ 2011-09-20 21:33 UTC (permalink / raw)
To: openembedded-core
In non-multilib packages, configured in a multilib configuration we
need to adjust the system provides and rprovides to include the
virtual multilib variant.
This resolves a problem introduced in the
329d864f9bbf94ad3aae8df43d63fe10e4237e4f commit. Where "allarch"
packages were suddenly providing all variants of an object.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
meta/classes/multilib_global.bbclass | 30 +++++++++++++++++++++++++-----
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/meta/classes/multilib_global.bbclass b/meta/classes/multilib_global.bbclass
index ed14565..c9bbe8f 100644
--- a/meta/classes/multilib_global.bbclass
+++ b/meta/classes/multilib_global.bbclass
@@ -6,16 +6,36 @@ python multilib_virtclass_handler_global () {
if isinstance(e, bb.event.RecipeParsed) and not variant:
if bb.data.inherits_class('kernel', e.data) or bb.data.inherits_class('module-base', e.data) or bb.data.inherits_class('allarch', e.data):
- origprovs = provs = e.data.getVar("PROVIDES", True)
- rprovs = e.data.getVar("RPROVIDES", True)
variants = (e.data.getVar("MULTILIB_VARIANTS", True) or "").split()
+
+ # Process PROVIDES
+ origprovs = provs = e.data.getVar("PROVIDES", True) or ""
for variant in variants:
provs = provs + " " + multilib_map_variable("PROVIDES", variant, e.data)
- for pkg in e.data.getVar("PACKAGES", True).split():
- rprovs = rprovs + " " + variant + "-" + pkg
+ # Reset to original value so next time around multilib_map_variable works properly
e.data.setVar("PROVIDES", origprovs)
+ bb.warn("PROVIDES: %s" % (provs))
e.data.setVar("PROVIDES", provs)
+
+ # Process RPROVIDES
+ origrprovs = rprovs = e.data.getVar("RPROVIDES", True) or ""
+ for variant in variants:
+ rprovs = rprovs + " " + multilib_map_variable("RPROVIDES", variant, e.data)
+ # Reset to original value so next time around multilib_map_variable works properly
+ e.data.setVar("RPROVIDES", origrprovs)
+ bb.warn("RPROVIDES: %s" % (rprovs))
e.data.setVar("RPROVIDES", rprovs)
+
+ # Process RPROVIDES_${PN}...
+ for pkg in (e.data.getVar("PACKAGES", True) or "").split():
+ origrprovs = rprovs = e.data.getVar("RPROVIDES_%s" % pkg, True) or ""
+ for variant in variants:
+ rprovs = rprovs + " " + multilib_map_variable("RPROVIDES_%s" % pkg, variant, e.data)
+ rprovs = rprovs + " " + variant + "-" + pkg
+ # Reset to original value so next time around multilib_map_variable works properly
+ e.data.setVar("RPROVIDES_%s" % pkg, origrprovs)
+ bb.warn("RPROVIDES_%s: %s" % (pkg, rprovs))
+ e.data.setVar("RPROVIDES_%s" % pkg, rprovs)
}
addhandler multilib_virtclass_handler_global
@@ -35,7 +55,7 @@ def multilib_extend_name(variant, name):
def multilib_map_variable(varname, variant, d):
var = d.getVar(varname, True)
if not var:
- return
+ return ""
var = var.split()
newvar = []
for v in var:
--
1.7.3.4
^ permalink raw reply related [flat|nested] 10+ messages in thread