Hi Alexander (long time no see!), Thanks for clearing that up, I'll go ahead and fix the manpages.
Thanks, Jonatan On Mon, Jun 1, 2020 at 1:48 PM Alexander Kanavin <alex.kana...@gmail.com> wrote: > > This is intentional. We do not want to special case multilib variants of > packages, and they should all be co-installable. The correct behavior is to > fix manpage generation in foo, so that it is reproducible, and either does > not write the build timestamp at all into the file, or writes it based on > SOURCE_DATE_EPOCH (not sure if the latter works as intended in 2.6 though). > > Alex > > On Mon, 1 Jun 2020 at 13:20, Jonatan Pålsson <jonata...@gmail.com> wrote: >> >> Hello, >> >> I have a Yocto 2.6 build with multilib enabled. I also have the >> doc-pkgs IMAGE_FEATURE enabled. I have issues with lib32-foo-doc and >> foo-doc both installing manpages into the same location in the rootfs, >> which causes conflicts during do_rootfs of my image recipe. >> >> The way I understand it, there shouldn't be any issues with having >> lib32-foo-doc and foo-doc installing the same manpage, as long as the >> manpages from both packages are identical. My problem is that in some >> cases, the foo package is cached in sstate, but the lib32-foo package >> is not, and the manpage contains a timestamp of when it was built. >> This if course gives two different versions of the manpage. >> >> When the doc-pkgs IMAGE_FEATURE is enabled, >> IMAGE_INSTALL_COMPLEMENTARY is populated with "*-doc", which matches >> both lib32-foo-doc and foo-doc. This happens in image.bbclass. My >> current work-around for this is to set PACKAGE_EXCLUDE_COMPLEMENTARY >> to "lib32-*-doc" - which filters out all lib32 versions of the >> manpages. In the vast majority of cases, I suspect that the lib32 >> version of the docs and the "normal" version should have the same >> contents, which means that keeping only one version of the manpages >> would work. >> >> Is the inclusion of both lib32-foo-doc and foo-doc intentional in >> IMAGE_INSTALL_COMPLEMENTARY, or is this a mistake? If it is a mistake, >> do you have any suggestions on what the correct behavior would be? >> Excluding all packages with the MLPREFIX seems to work in my case, but >> it seems like an inelegant approach. >> >> Thanks, >> Jonatan >>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#84708): https://lists.openembedded.org/g/openembedded-devel/message/84708 Mute This Topic: https://lists.openembedded.org/mt/74601304/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
