On Thursday 23 May 2013 09:40:51 Mark Hatle wrote: > On 5/23/13 3:01 AM, Ming Liu wrote: > > 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 multilib 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. > > > > [YOCTO #4532] > > [ CQID: WIND00416824 ] > > > > Signed-off-by: Ming Liu <[email protected]> > > 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.)
This is the same problem as bug 4408: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4408 It's a bit nasty to have to solve this on a per-recipe basis; we need some kind of generic solution. At the moment I'm not sure what that would be however. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
