Bug 13418 - Multilib and update-alternatives conflict
Summary: Multilib and update-alternatives conflict
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 2.8
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 2.8 M2
Assignee: Robert Yang
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2019-06-25 14:56 UTC by Ross Burton
Modified: 2019-06-27 14:56 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ross Burton 2019-06-25 14:56:00 UTC 
If a multilib image contains both lib32-libtool and libtool then you get warnings:

update-alternatives: libtool has multiple providers with the same priority, please check /home/pokybuild/yocto-worker/multilib/build/build/tmp/work/qemux86-pokymllib64-linux/lib64-core-image-sato-sdk/1.0-r0/rootfs/usr/lib/opkg/alternatives/libtool for details

Both libtool and lib32-libtool have the same priority (as they're the same recipe), so update-alternatives won't deterministically pick a provider. This means you could end up with an image using a 32-bit pkgconfig and 64-bit libtool, for example.

update-alternatives and multilib should cooperate to solve this, for example by reducing the priority of multilib'd providers by 1 so the primary architecture is preferred if both are installed.

Robert, assigning this to you as we thought that you might have fixed this already.  We were right?
Comment 1 Robert Yang 2019-06-26 07:45:09 UTC 
I didn't fix it, but I think that I can fix it:-).