[PATCH] image/populate_sdk: Support usrmerge for nativesdk in SDK builds

[PATCH] image/populate_sdk: Support usrmerge for nativesdk in SDK builds

[Sean Nyekjaer]

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.

Signed-off-by: Sean Nyekjaer <sean@geanix.com>
---
 meta/classes-recipe/populate_sdk_base.bbclass | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/populate_sdk_base.bbclass b/meta/classes-recipe/populate_sdk_base.bbclass
index 98ac723552c..edd9da91712 100644
--- a/meta/classes-recipe/populate_sdk_base.bbclass
+++ b/meta/classes-recipe/populate_sdk_base.bbclass
@@ -200,7 +200,14 @@ create_merged_usr_symlinks_sdk() {
     create_merged_usr_symlinks ${SDK_OUTPUT}${SDKTARGETSYSROOT}
 }
 
-POPULATE_SDK_PRE_TARGET_COMMAND += "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', 'create_merged_usr_symlinks_sdk', '',d)}"
+create_merged_usr_symlinks_nativesdk() {
+    create_merged_usr_symlinks ${SDK_OUTPUT}${SDKPATHNATIVE}
+}
+
+POPULATE_SDK_PRE_TARGET_COMMAND += " \
+    ${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', 'create_merged_usr_symlinks_sdk', '',d)} \
+    ${@bb.utils.contains('DISTRO_FEATURES_NATIVESDK', 'usrmerge', 'create_merged_usr_symlinks_nativesdk', '',d)} \
+"
 
 SDK_PACKAGING_COMMAND = "${@'${SDK_PACKAGING_FUNC}' if '${SDK_PACKAGING_FUNC}' else ''}"
 SDK_POSTPROCESS_COMMAND = "create_sdk_files check_sdk_sysroots archive_sdk ${SDK_PACKAGING_COMMAND}"
-- 
2.47.1

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

[Ross Burton]

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?

Cheers,
Ross

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

[Sean Nyekjaer]

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

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

[Sean Nyekjaer]

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?

/Sean

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

[Richard Purdie]

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.

If systemd was truly "cross", you wouldn't need to force the target
layout into the SDK. The SDK layout should be independent of the target
system and this breaks that understanding. If we accept this patch, how
can one SDK work with different init systems?

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

Cheers,

Richard

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

[Esben Haabendal]

"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

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

[Richard Purdie]

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.

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. We'd at least need to make
sure there were clear errors about why the configuration wouldn't work.

These two factors combined effectively forces everyone to that layout
whether they want to use it or not.

I really don't like imposing design choices like that by stealth.

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. If we did it, we should do it properly and for example
skip the symlinks since we control all the code. That would probably
break systemd too though since that wouldn't match it's world view
either.

I've been reluctant to go down the single bindir path before because I
know who will get all the bug reports to fix. I worry that will be the
case for usrmerge in the SDK too since people like to apply a bandaid
to make their specific use case work, then move on. I totally
understand why but it does make me reluctant to take such changes. I'd
also mention, how often do I actually say "no" to changes? I can think
of only two in the current development cycle, both complicating the
SDK.

Cheers,

Richard

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

[Esben Haabendal]

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?

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"?

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.

> 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.

> 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.

> 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.

> 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.

> That would probably break systemd too though since that wouldn't match
> it's world view either.

Yes. And a lot of people would not see the benefit in breaking systemd
for the use.

> I've been reluctant to go down the single bindir path before because I
> know who will get all the bug reports to fix. I worry that will be the
> case for usrmerge in the SDK too since people like to apply a bandaid
> to make their specific use case work, then move on. I totally
> understand why but it does make me reluctant to take such changes. I'd
> also mention, how often do I actually say "no" to changes? I can think
> of only two in the current development cycle, both complicating the
> SDK.

Switching SDK to usrmerge looks like a simplification to me.

/Esben

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

[Richard Purdie]

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

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

[Esben Haabendal]

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

> 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.

Ok. So by official, I guess you mean implied. Fair enough.

>> 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.

Probably, yes.

> 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?

Is it officially not supported?

How can a developer know that?

>> 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.

Ok. I guess that is your position then.

>> > 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?

No. And you are being completely unreasonable here.

We are discussing placing a single symlink in the SDK, and know you are
implying that this is a part of a greater plan for removing support for
musl and sysvinit.

Sorry, but that is just being bully.

>> > 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.

Are you imaging that by refusing to support systemd tools in
OpenEmbedded SDK images that systemd is going to change anything? I am
pretty sure you know that is not going to happen.

So the only that loose out on this approach is loose out is OpenEmbedded
project and users.

>> > 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.

In this case, you are the one that refuses the option of customizing it
with the usrmerge feature.

And in this case, the SDK is not working, and allowing customization
with usrmerge is a way to fix that.
Refusing that, without suggesting any alternative solutions are not
productive IMHO.

>> > 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.

Of-course. But this might not be such a time, as OpenEmbedded really is
flexible enough to be able to support something so innocent as usrmerge
in SDK.

But I guess you have decided that we will have to do that in a way so
that will not be shared with other OE users falling into the same trap.

/Esben

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

[Richard Purdie]

On Wed, 2025-02-05 at 11:29 +0100, Esben Haabendal via lists.openembedded.org wrote:
> "Richard Purdie via lists.openembedded.org"
> <richard.purdie=linuxfoundation.org@lists.openembedded.org> writes:
> > > > 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?
> 
> No. And you are being completely unreasonable here.
> 
> We are discussing placing a single symlink in the SDK, and know you are
> implying that this is a part of a greater plan for removing support for
> musl and sysvinit.
> 
> Sorry, but that is just being bully.

There are other ways to solve this problem. 

Sean said you need libudev in nativesdk and I'd imagine there are other
ways to manage to build that without changing the whole SDK layout.
Sure, that is probably a path of least resistance but my point is that
I don't think it is the right one.

One of my jobs as maintainer is to say "no", at least occasionally. I
don't like doing that, I don't like resulting accusations of being a
bully, being brainless and making OE worse. It makes me wonder about
resigning and walking away from all of this as I sometimes feel I've
just about had enough of it. Does anyone actually care since I'm making
things so bad. 

Not every decision is one everyone will 100% agree with and sadly, that
is an unfortunate consequence of having to make a decision in the first
place. I do merge a lot of things I don't like or agree with.

FWIW I'm also told I don't say no nearly often enough :/.

> > > 
Richard

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

[Sean Nyekjaer]

On Wed, Feb 05, 2025 at 11:10:37AM +0100, Richard Purdie wrote:
[...]
> 
> There are other ways to solve this problem. 
> 
> Sean said you need libudev in nativesdk and I'd imagine there are other
> ways to manage to build that without changing the whole SDK layout.
> Sure, that is probably a path of least resistance but my point is that
> I don't think it is the right one.
> 

Yes, I'll manage :/

As I have seen on the mailinglist, I was not the only one with this problem.

My professional pride does take a hit when I see an issue and not being
able to fix it.
I think it would be a nicer to abort the sdk build, if one sets usrmerge for
nativesdk, than having the sdk fail at install time.

/Sean