Generic implementation details as well as details that are specific to package management systems exist. Following are implementation details that exist regardless of the package management system:
The typical convention used for the
class extension code as used by
Multilib assumes that all package names specified
in
PACKAGES
that contain ${PN}
have
${PN}
at the start of the name.
When that convention is not followed and
${PN}
appears at
the middle or the end of a name, problems occur.
The
TARGET_VENDOR
value under Multilib will be extended to
"-vendor
mlmultilib
"
(e.g. "-pokymllib32" for a "lib32" Multilib with
Poky).
The reason for this slightly unwieldy contraction
is that any "-" characters in the vendor
string presently break Autoconf's
config.sub
, and
other separators are problematic for different
reasons.
For the RPM Package Management System, the following implementation details exist:
A unique architecture is defined for the Multilib packages,
along with creating a unique deploy folder under
tmp/deploy/rpm
in the
Build Directory.
For example, consider lib32
in a
qemux86-64
image.
The possible architectures in the system are "all", "qemux86_64",
"lib32_qemux86_64", and "lib32_x86".
The ${MLPREFIX}
variable is stripped from
${PN}
during RPM packaging.
The naming for a normal RPM package and a Multilib RPM package in a
qemux86-64
system resolves to something similar to
bash-4.1-r2.x86_64.rpm
and
bash-4.1.r2.lib32_x86.rpm
, respectively.
When installing a Multilib image, the RPM backend first installs the base image and then installs the Multilib libraries.
The build system relies on RPM to resolve the identical files in the two (or more) Multilib packages.
For the IPK Package Management System, the following implementation details exist:
The ${MLPREFIX}
is not stripped from
${PN}
during IPK packaging.
The naming for a normal RPM package and a Multilib IPK package in a
qemux86-64
system resolves to something like
bash_4.1-r2.x86_64.ipk
and
lib32-bash_4.1-rw_x86.ipk
, respectively.
The IPK deploy folder is not modified with
${MLPREFIX}
because packages with and without
the Multilib feature can exist in the same folder due to the
${PN}
differences.
IPK defines a sanity check for Multilib installation using certain rules for file comparison, overridden, etc.