On 01/07/2016 06:57 PM, Richard Purdie wrote:
On Wed, 2016-01-06 at 23:45 -0800, Robert Yang wrote:
The dependencies chain:
run-postinsts -> update-rc.d.bbclass -> initscripts -> update
-alternatives.
The update-alternatives is provided by opkg-utils which is not
allarch.
This caused a problem:
$ bitbake lib32-core-image-minimal
Both lib32-opkg-utils and opkg-utils would be built, but opkg-utils
shouldn't, this patch can fix the problem.
[YOCTO #8879]
Signed-off-by: Robert Yang <liezhi.y...@windriver.com>
---
.../run-postinsts/run-postinsts_1.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Removing allarch isn't the correct way to fix this, we need to figure
out what is going wrong and fix multilib.
After more investigations, it seems that there is no easy way to fix
the problem, maybe we need choose not fix it atm. Here is a short summary.
* Problem
When mutilib is enabled, for example:
MACHINE ?= "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
$ bitbake core-image-minimal
We will see that a few 64 bit pkgs will be built, for example, 64 bit
python, bash, openssl, opkg-utils and, but they shouldn't, since it
doesn't make any sense to build them since they are not going to be
installed on the target by default.
* Root Cause
This is caused by run-postinsts is allarch since:
$ bitbake lib32-run-postinsts
run-postinsts (no lib32 since it is an allarch pkg) would be built,
it depends on non-allarch recipe opkg-utils, and opkg-utils depends
on others, a simple graph.
core-image-minimal -> run-postinsts -> opkg-utils
lib32-core-image-minimal -> (lib32-)run-postinsts -> opkg-utils (should be
lib32)
We can see that lib32-run-postinsts breaks multilib's dependencies chain,
and there is no easy way fix the problem AFAIK.
* What I have tried
- Extend allarch to lib32-allarch, this would changed a lot on allarch,
and if we extend it, allarch is not really "all arch".
- Let each recipe provides a lib32allarch-recipe when extend multilib,
which is used for allarch recipe depends on it, and let bitbake decide
which to run for example:
opkg-utils *provides* lib32allarch-opkg-utils
lib32-opkg-utils *provides* lib32allarch-opkg-utils
And then:
run-postinsts *depends* lib32allarch-opkg-utils
Both opkg-utils and lib32-opkg-utils provides lib32allarch-opkg-utils,
then let bitbake choose a proper to build according what you are building,
(lib32-recipe -> lib32-opkg-utils, recipe -> opkg-utils) this also
need modify bitbake's PREFERRENCE_PROVIDER policies, which seems not worth,
so I drop this idea.
Any suggestions is appreciated.
// Robert
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
