From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>,
Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 3/6] sstate: Stop allowing overlapping symlinks from sstate
Date: Mon, 25 Sep 2023 15:59:16 +0100 [thread overview]
Message-ID: <4050f808f3123fd5decc61b90926f57608a35eb2.camel@linuxfoundation.org> (raw)
In-Reply-To: <CA+chaQdisk-vWfuRvOuK4dGag2coDqJX89OSf_T2YrZEqPSxcg@mail.gmail.com>
On Sun, 2023-09-24 at 11:14 +0200, Martin Jansa wrote:
> Just FYI I think this change is now causing few more recipes to be mutually exclusive, when they build the same library (even when it's packaged in differently named package), in world builds I'm seeing e.g. libslirp and libslirp-virt (from meta-virtualization) causing packagedata failure for one of them (depending which one was built second):
>
> DEBUG: Staging files from TOPDIR/BUILD/work/raspberrypi4_64-oe-linux/libslirp-virt/4.6.1+git/pkgdata-pdata-input to TOPDIR/BUILD/pkgdata/raspberrypi4-64
> ERROR: Recipe libslirp-virt is trying to install files into a shared area when those files already exist. The files and the manifests listing them are:
> TOPDIR/BUILD/pkgdata/raspberrypi4-64/runtime-reverse/libslirp-dev
> (matched in manifest-raspberrypi4_64-libslirp.packagedata)
> TOPDIR/BUILD/pkgdata/raspberrypi4-64/runtime-reverse/libslirp0
> (matched in manifest-raspberrypi4_64-libslirp.packagedata)
> TOPDIR/BUILD/pkgdata/raspberrypi4-64/runtime-reverse/libslirp-dbg
> (matched in manifest-raspberrypi4_64-libslirp.packagedata)
> TOPDIR/BUILD/pkgdata/raspberrypi4-64/runtime-reverse/libslirp-src
> (matched in manifest-raspberrypi4_64-libslirp.packagedata)
> Please adjust the recipes so only one recipe provides a given file.
> DEBUG: Python function sstate_task_postfunc finished
>
> Bruce is 4.6.1 version in meta-virtualization still needed or can you update to libslirp 4.7.0 from oe-core?
> From the git log https://git.yoctoproject.org/meta-virtualization/log/recipes-networking/slirp it looks like it was originally imported from meta-retro and later renamed from libslirp to libslirt-virt until the oe-core version is validated in runtime.
>
> And I'm seeing the same with some internal recipes (e.g. we have faultmanager recipe which provides libfm - completely different from libfm from oe-core, just library name coincidence).
I did look into this and it *is* a real issue/bug. The output will be
non-deterministic depending upon which is built first. The issue would
"corrupt" anything which is reading data from pkgdata related to the
recipes in question.
The error is therefore correct and we need to do something about this.
Cheers,
Richard
next prev parent reply other threads:[~2023-09-25 14:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-20 10:57 [PATCH 1/6 v2] license/license_image: Fix license file layout to avoid overlapping files Richard Purdie
2023-09-20 10:57 ` [PATCH 2/6 v2] create-spdx/sbom: Ensure files don't overlap between machines Richard Purdie
2023-09-20 10:57 ` [PATCH 3/6] sstate: Stop allowing overlapping symlinks from sstate Richard Purdie
2023-09-24 9:14 ` [OE-core] " Martin Jansa
2023-09-24 10:10 ` Richard Purdie
2023-09-25 14:59 ` Richard Purdie [this message]
2023-09-25 17:19 ` Martin Jansa
2023-09-20 10:58 ` [PATCH 4/6] sstate: Fix nativesdk entry in SSTATE_ARCHS Richard Purdie
2023-09-20 10:58 ` [PATCH 5/6 v2] multilib: fix SSTATE_ARCHS for multilib usage Richard Purdie
2023-09-20 10:58 ` [PATCH 6/6] oeqa/selftest/bbtests: Improve and update test_non_gplv3 Richard Purdie
2023-12-19 1:11 ` [OE-core] [PATCH 1/6 v2] license/license_image: Fix license file layout to avoid overlapping files Russ Dill
2024-07-17 20:29 ` Livius
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4050f808f3123fd5decc61b90926f57608a35eb2.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=bruce.ashfield@gmail.com \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox