On Wed, 2025-02-05 at 10:53 +0100, Esben Haabendal wrote: > Richard Purdie <[email protected]> writes: > > > On Wed, 2025-02-05 at 09:28 +0100, Esben Haabendal wrote: > > > "Richard Purdie via lists.openembedded.org" > > > <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#210839): https://lists.openembedded.org/g/openembedded-core/message/210839 Mute This Topic: https://lists.openembedded.org/mt/110665235/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
