Re: [OE-core] [PATCH] usrmerge: add the distro feature to nativesdk builds when added to target and enable symlink creation for both

[Richard Purdie <richard.purdie@linuxfoundation.org>]

Hi Alejandro,

On Thu, 2024-02-15 at 12:10 -0700, Alejandro Enedino Hernandez
Samaniego wrote:
> On 2/6/24 03:27, Richard Purdie wrote:
> > 
> > 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?
> 
>
> 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.

I think there is a piece of this that is still missing. Changing
usrmerge in nativesdk fundamentally alters the layout of the SDK. The
layout of the SDK is meant to be independent of the target (think
multilibs and so on as well).

What that means is that the tools are meant to work with any target
system and not need to "match" their layout. This effectively means
that systemd's tools aren't working properly for environments which
have cross layouts.

The SDK layout is already drastically different from that of the target
system in that everything is installed into a deep prefix path. How
long will it be before systemd drops support for that too?

I don't really buy into this "systemd should dictate the layout of
everything" situation we're ending up in. It does mean any given SDK
can only support systemd or not systemd but not both so it breaks
multiconfig too.

What is systemd's position on supporting cross environments? That is
effectively the real question here and it sounds like they don't
support that? We already have big issues with this in the "native"
tooling side of things since that cross support doesn't exist and we
had to do our own emulation.

So whilst I understand your usecase, I do believe this is a sign of a
much deeper problem unfortunately, namely that systemd doesn't support
cross environments or usage. We could probably hack around it like this
for now but I'm far from sure it won't just break again in the future
in worse ways.

Cheers,

Richard