[OE-core] [PATCH 2/3] run-postinsts: can't be allarch

[Robert Yang]

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.yang at 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
>