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

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

On Wed, 2025-02-05 at 10:53 +0100, Esben Haabendal wrote:
> Richard Purdie <richard.purdie@linuxfoundation.org> writes:
> 
> > On Wed, 2025-02-05 at 09:28 +0100, Esben Haabendal wrote:
> > > "Richard Purdie via lists.openembedded.org"
> > > <richard.purdie=linuxfoundation.org@lists.openembedded.org> writes:
> > > > > 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.
> > 
> > Play out this scenario. Firstly, we would now officially have to
> > support two different SDK layouts. The alternative is we don't test one
> > of them, which would imply one of them is broken some of the time.
> 
> What do you mean with "officially" here?

Tested on the autobuilder. Taking that patch would be taken as a sign
we planned to support that workflow.

> Right now, as I showed you, you can try and add usrmerge to
> DISTRO_FEATURES_NATIVESDK, causing SDK to fail.
> Are you saying that we should see that as a "feature"?

You can do lots of things. If we take patches fixing things it does
imply that workflow becomes more supported.

If someone files a bug about usrmerge in nativesdk, are you saying I
can still close it as "not supported" even after I merge patches fixing
it?

> As it stands now, anyone that for whatever reason comes up with the idea
> of adding usrmerge to DISTRO_FEATURES_NATIVESDK will run into this
> problem. Is that a good thing?
> 
> > As soon as someone wants to include systemd-repart or libudev or one of
> > these other tools, we'd effectively force the selection of usrmerge in
> > the SDK since it won't build/work otherwise.
> 
> No, we would not be forcing users to do that. The tools that are
> implemented that way is forcing that choice.
> 
> It seems to me that your suggestion is that Yocto users should not be
> allowed to use such tools. At least not without out-of-tree patching.
> Please correct me if I am wrong.

I'm saying that out of tree patching in this case is definitely
preferable.

> > We'd at least need to make sure there were clear errors about why the
> > configuration wouldn't work.
> 
> Do you mean
> 
> 1. Why adding usrmerge to DISTRO_FEATURES_NATIVESDK won't work?
> 
> 2. Why tool X, Y, Z won't work as nativesdk tools?
> 
> As for the answer to 1, it is because you are not accepting fixes to it.
> 
> As for answer to 2, that will be an uphill battle, as more and more
> tools are starting to assume usrmerge style layouts. It doesn't matter
> if you like it or not, but given the dominance of systemd, it will
> happen.

We should just do what systemd says and drop support for musl, sysvinit
and anything else systemd says?

> > These two factors combined effectively forces everyone to that layout
> > whether they want to use it or not.
> 
> Switching to only supporting usrmerge style SDK layout would be fine
> IMHO.
> 
> > I really don't like imposing design choices like that by stealth.
> 
> You/we are not doing that. Somebody else is doing that. If you like it
> or not is not really important. It is there.

We don't have to just accept it.

> > To be honest I'd probably agree about only needing one bindir but what
> > I object to is doing it via usrmerge and doing it because systemd
> > requires it.
> 
> Sorry, but that is knowingly making OpenEmbedded a worse tool, without
> any benefit. If we switch to having one bindir, placing a symlink to
> make stuff work is a no-brainer.

I very strongly disagree.

The point is that OE supports customisation and layout is one of those
things. We use layout customisation to make the SDK work at all.
Removing/limiting the ability to customise undermines one of OE's key
values. Even chipping away at the edges of that will ultimately
undermine it.

> > If we did it, we should do it properly and for example
> > skip the symlinks since we control all the code.
> 
> Most of the code is only under our control as far as we are willing to
> patch it.
> I believe reducing the amount of patches to 3rd party software was a
> good thing.

It is, but there is also sometimes a need to patch things.


> 
Richard