From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/7] rootfs_rpm: Use specific MACHINE_ARCH for multilib recipes
Date: Tue, 20 Sep 2011 22:50:23 +0100 [thread overview]
Message-ID: <1316555432.14488.88.camel@ted> (raw)
In-Reply-To: <2539230a1b1e941f43d6b6b3b686d90dac900410.1316553828.git.mark.hatle@windriver.com>
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
next prev parent reply other threads:[~2011-09-20 21:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
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:50 ` Richard Purdie [this message]
2011-09-20 23:49 ` Xu, Dongxiao
2011-09-20 21:33 ` [PATCH 2/7] multilib: install MULTILIB_IMAGE_INSTALL Mark Hatle
2011-09-20 21:33 ` [PATCH 3/7] Fix RPM dependencies Mark Hatle
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 ` [PATCH 5/7] Update python dependencies to be simply to "python" 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
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=1316555432.14488.88.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox