Hi Martin,
On 2018年06月28日 19:13, Martin Jansa wrote:
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.
Thanks for your reply.
We have too many different kind of images so it can't be assured that
lib32-openssl will be installed to image. And there are also other
noarch packages such as docbook-xsl-stylesheets which depends on perl.
It is better to have a common solution.
Thanks,
Kai
On Thu, Jun 28, 2018 at 10:48 AM Kang Kai <[email protected]
<mailto:[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]
<mailto:[email protected]>
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Regards,
Neil | Kai Kang
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
