Re: [OE-core] [PATCH] image/populate_sdk: Support usrmerge for nativesdk in SDK builds

[Esben Haabendal <esben@geanix.com>]

"Richard Purdie via lists.openembedded.org"
<richard.purdie=linuxfoundation.org@lists.openembedded.org> writes:

> On Tue, 2025-02-04 at 14:59 +0100, Sean Nyekjaer via
> lists.openembedded.org wrote:
>> Hi Ross,
>> 
>> On Wed, Jan 22, 2025 at 03:04:35PM +0100, Sean Nyekjaer wrote:
>> > On Wed, Jan 22, 2025 at 01:41:11PM +0100, Ross Burton wrote:
>> > > Hi Sean,
>> > > 
>> > > On 17 Jan 2025, at 13:08, Sean Nyekjaer via
>> > > lists.openembedded.org <sean=geanix.com@lists.openembedded.org>
>> > > wrote:
>> > > > Some recipes(systemd) requires usrmerge. Create the required
>> > > > symlinks for `/bin`, `/lib` and `/sbin`, when installing
>> > > > nativesdk
>> > > > packages.
>> > > > Enable the symlink creation by setting the `usrmerge` flag in
>> > > > DISTRO_FEATURES_NATIVESDK.
>> > > 
>> > > This implies that there is some layout dependency between the
>> > > target and the sdk environment. There really shouldn't be, what
>> > > broke to cause you to send this?
>> > 
>> > Hi Ross,
>> > 
>> > In order to build and test our rust programs, we need libudev which
>> > systemd is providing.
>> > We are running our tests with nativesdk.
>> > 
>> > Systemd is requires usrmerge.
>> > 
>> > Hope that explains :)
>> > 
>> > /Sean
>> 
>> Forgot to ask you yesterday at the OE Workshop.
>> 
>> Is anything holding this back?
>
> Yes, there is.
>
> You're using the SDK in a way which it wasn't really intended for and
> we're seeing "feature creep" where systemd's requirements being pushed
> into places they don't really belong.

Applying "usrmerge" to SDK is not a systemd feature as such. In my
opinion, not splitting binaries in multiple bin dirs in general makes
sense for an SDK. And throwing in a simple symlink for making stuff
work, is super innocent in my opinion (for whatever that is worth).

What is so fundamentally wrong or bad in allowing people to create SDK
with usrmerge?

> If systemd was truly "cross", you wouldn't need to force the target
> layout into the SDK.

There is no pushing of target layout into the SDK. The need or desire
for having usrmerge in SDK is independent of target layout as such.
Of-course, if you are having any kind of systemd tools in SDK, chances
are that you are including some systemd features in target rootfs as
well. But in theory, it is really independent.

It is totally possible to for example want to include systemd-repart
command in SDK and not have anything systemd in target rootfs.

> The SDK layout should be independent of the target
> system and this breaks that understanding.

I agree on the former, and disagree on the latter. What Sean is pushing
here allows people to build SDK with a usrmerge style layout. If they
want to use usrmerge layout in rootfs layout or not is a different
story.

> If we accept this patch, how can one SDK work with different init
> systems?

Why should it not work with other init systems?

1. Accepting this patch will not change anything for anyone not
explicity adding usrmerge to DISTRO_FEATURES_NATIVESDK ?

2. Whatever init systems is in rootfs does not rely the use of usrmerge
in the SDK. Adding systemd utilities might, but it is another thing.

> So I don't really feel it appropriate to merge this change, sorry.

What is your general opinion on using usrmerge in SDK layout? Is it
something that is not supposed to be working, or will you accept fixes
for it?

Adding this to local.conf does not produce a working SDK:

DISTRO_FEATURES_NATIVESDK:append = " usrmerge"

Sean is simply trying to fix that.

/Esben