Maybe the better thing to do would be to name the packages in the first place in such a way that openssl is a 32 bit package, and lib64-openssl is the 64 bit one. Then any noarch package would pull in the correct version automatically. Is that not possible somehow?
Alex 2018-06-28 13:13 GMT+02:00 Martin Jansa <[email protected]>: > In our build I've removed the openssl runtime dependency > (RDEPENDS_${PN}_remove = "openssl"), because we pull the right version of > openssl (lib32-openssl in our case) to the image elsewhere. > > On Thu, Jun 28, 2018 at 10:48 AM Kang Kai <[email protected]> wrote: >> >> Hi all, >> >> When build 32 bits rootfs with 64 bits bsp, if an allarch/noarch package >> is installed to lib32 rootfs, it causes >> unexpected 64 bits packages which is required by the allarch package >> installed to lib32 rootfs. >> >> Take ca-certificates as example. ca-certificates rdepends on openssl, so >> if ca-certificates is installed to image, >> 64 bits package openssl will be installed too no matter what the rootfs >> is. But only 32 bits openssl package should >> be installed to 32 bits rootfs. >> >> There are 2 ways to fixed the issue. >> >> 1 expand allarch/noarch packages with multilib. So if add ca-certificates >> to image, lib32-ca-certificates will be >> installed to 32bits rootfs. And then also the dependency lib32-openssl >> is installed. That is what we expected. >> >> 2 expand DEPENDS/RDEPENDS of allarch/noarch packages with a prefix >> 'noarch-' when multilib is enabled. So then >> ca-certificates requires 'noarch-openssl'. And make both lib32-openssl >> and openssl provides 'noarch-openssl'. >> When do_rootfs, there is only one rpm repo 'oe-rootfs-repo' now. We >> will create repos with different priorities >> according to different archs/subdirectories. For 32 bits image, make 32 >> bits rpm repo has higher priority, so lib32-openssl >> will be installed to 32 bits rootfs rather than 64bits. >> >> I know these 2 ways are not perfect, but only possible ways I have in mind >> to solve the problem. >> >> Any comment or suggestion is greatly appreciated. Thanks a lot. >> >> -- >> Regards, >> Neil | Kai Kang >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> [email protected] >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > -- > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
