On Thu, 2024-02-01 at 02:56 +0000, Maanya Goenka wrote:From: Maanya Goenka <maanyagoenka@microsoft.com> Add usrmerge to DISTRO_FEATURES_FILTER_NATIVESDK (and DISTRO_FEATURES_FILTER_NATIVE for consistency), since we have come across cases where the distro feature would be required by both contexts. As a supplement to this change, when creating the merged usr symlinks at the do_populate_sdk stage, these need to be created for both the target and native sysroots within the SDK. Signed-off-by: Maanya Goenka <maanyagoenka@microsoft.com> Signed-off-by : Alejandro Hernandez Samaniego <alhe@linux.microsoft.com> --- meta/classes-recipe/image.bbclass | 2 ++ meta/conf/bitbake.conf | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-)This doesn't quite follow. "target", "nativesdk" and "native" are all different separate filesystems and not connected. Yes, you can use usrmerge on some (or all?) of them but you don't have to have them match. Forcing them to match is likely just working around an underlying issue which needs to be fixed. What were the real failures?
Hello Richard,
Apologies for the late response. I do agree that target, native and nativesdk are all separate and that you could use usrmerge on some or all. I understand your point and I'm to blame for the suggestion to add usrmerge to the NATIVE case for consistency. The proposed patch is trying to fix an issue for a use case related to systemd. Newer versions of systemd do not function properly without usrmerge because upstream systemd is dropping support for non-usrmerge cases, which is typically fine because usrmerge works well for the TARGET. https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html However, we are using some NATIVESDK systemd components that require usrmerge to work as well hence why we needed to add usrmerge to the NATIVESDK filter since systemd components where expecting usr/foo locations in the nativesdk filesystem. While I understand that using nativesdk systemd components may not be widely common, I do believe its a valid usecase. I'd like to clarify that I'm not aware of any native systemd usecase and that my suggestion to add usrmerge to the NATIVE filter was only for consistency, but not required (apologies for that again). I've reproduced the autobuilder failures locally and I see that taking out usrmerge from the NATIVE filter does get rid of the errors, if you agree with my statement that nativesdk systemd components are a valid usecase, we can send a v2 that adds usrmerge to the NATIVESDK filter only to fix such cases. If you prefer, we could also go one step above that and create a condition to add usrmerge to the NATIVESDK filter only if systemd is being used or something similar. Cheers, Alejandro
For example, this would stop native or nativesdk sstate being reused between differently configured builds when it could be. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#194983): https://lists.openembedded.org/g/openembedded-core/message/194983 Mute This Topic: https://lists.openembedded.org/mt/104089708/4354175 Group Owner: openembedded-core+owner@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alhe@linux.microsoft.com] -=-=-=-=-=-=-=-=-=-=-=-