a684808899
libpam might miss ABI specific dependencies for pam-plugins-*, for RPM uses generic names to check the packages depending on it and doesn't consider the arch, which will lead to packaging issues in mulbilib build. pam_plugin_hook is added because the plugin packages are dynamically generated, so we need to manually process multilib names by add baselib to RPROVIDES/RDEPENDS as ABI specific tag. (From OE-Core rev: d08e64a98316d7659b0fb56812667c534f66a1a8) Signed-off-by: Ming Liu <ming.liu@windriver.com> I worked with Ming Liu on this particular issue. You may wonder why this is necessary let me attempt to explain the underlying causes. In deb/ipk on a multilib package, the package name has specific multilib references in it. I.e. the alternative libraries start with something like lib32-... This was done primarily because deb/ipk do not allow two packages with the same name (but different architectures) to be installed at the same time. So the name has to be unique. In RPM however, the names of the packages and matches with the architectures and if they are not the same we can do these multilib installs. This matches the behavior of other RPM based distributions and in many ways the tools people are used to working with RPM. For the most part this works fine in multilib configurations because additional per-file dependencies are added that capture the shared library dependencies with ABI specific information. This unfortunately fails in a few cases where plugins are dynamically loaded via dlopen -- such as libpam. One possible fix is simply to follow the deb/ipk package naming, but this causes a design advantage of rpm. When a package has a dependency on 'bash', we really don't care what bash is installed, only that -a- bash is installed. In the deb/ipk case, the lib32- packages would end up with a lib32-bash dependency and you could potentially end up with two 'bash' packages being installed. So the fix I recommended for the issue was to add the baselib path to the internal dependencies. Since we know that the libpam installed in 'lib' needs the modules that were compiled to also work with the 'lib' version of libpam. While the libpam in 'lib64' need the modules to work with the 'lib64' version of the plugins. Existing dependencies are preserved so there is no impact in the ipk/deb case, the RPM case is resolved as the additional dependency information is now present for the package manager to select the package we really want. If anyone else has a suggestion for an alternative fix, we're interested -- but this is the best answer we could come up with. (If any of the above should be added to the commit message, the YP bug, or documentation, please let me know and I'll make sure it gets added.) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> [YOCTO #4532] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Poky
Poky is an integration of various components to form a complete prepackaged build system and development environment. It features support for building customised embedded device style images. There are reference demo images featuring a X11/Matchbox/GTK themed UI called Sato. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK with IDE integration.
Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of layers which extend the systems capabilities in a modular way.
As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation and various sources of information e.g. for the hardware support. Poky is in turn a component of the Yocto Project.
The Yocto Project has extensive documentation about the system including a reference manual which can be found at: http://yoctoproject.org/documentation
OpenEmbedded-Core is a layer containing the core metadata for current versions of OpenEmbedded. It is distro-less (can build a functional image with DISTRO = "nodistro") and contains only emulated machine support.
For information about OpenEmbedded, see the OpenEmbedded website: http://www.openembedded.org/
Where to Send Patches
As Poky is an integration repository, patches against the various components should be sent to their respective upstreams.
bitbake: bitbake-devel@lists.openembedded.org
meta-yocto: poky@yoctoproject.org
Most everything else should be sent to the OpenEmbedded Core mailing list. If in doubt, check the oe-core git repository for the content you intend to modify. Before sending, be sure the patches apply cleanly to the current oe-core git repository. openembedded-core@lists.openembedded.org
Note: The scripts directory should be treated with extra care as it is a mix of oe-core and poky-specific files.