Rootfs conflicts when using multilib and doc-pkgs

Rootfs conflicts when using multilib and doc-pkgs

[Jonatan Pålsson]

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

Re: [oe] Rootfs conflicts when using multilib and doc-pkgs

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

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 <jonatan.p@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
> 
>

[-- Attachment #2: Type: text/html, Size: 2506 bytes --]

Re: [oe] Rootfs conflicts when using multilib and doc-pkgs

[Jonatan Pålsson]

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.kanavin@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 <jonatan.p@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
>>