Some of the OE TSC discussed the upcoming LTS yesterday and concluded that there are some tweaks we should make before we reach the next LTS release.
Firstly, DISTRO_FEATURES. Basically, we'd like to propose reconciling those in nodistro in OE-Core with those in poky. Poky has in addition: opengl ptest multiarch wayland vulkan The reasons for adding these by default would be: a) Ensure recipe upgrades are tested in a more useful way. Currently, with opengl and ptest disabled, recipe upgrades often fail if they were written against nodistro. This would avoid this in many cases. b) Allow for better sstate reuse. We have a nicely functioning CDN for sstate now but it is generated by the Yocto Project Autobuilder. The closer nodistro matches the configuration used on there for testing, the better the cache matches c) Adapt to modern technology changes. Things like X11 are fading and we really should promote wayland for example. This brings us to the second set of changes. Other key changes poky makes are effectively: require conf/distro/include/no-static-libs.inc require conf/distro/include/yocto-uninative.inc require conf/distro/include/security_flags.inc require conf/distro/include/yocto-space-optimize.inc INHERIT += "uninative" This amounts to "uninative", "security tweaks" and "build speed/space optizations". I believe that these should all really become the defaults too, partly for b) above, to allow the CDN to function really well, but also because these are mature, well tested pieces of functionality. Uninative is key to sstate reuse across distros for native sstate objects. Security makes sense by default where we can. The build speed/space tweaks are generally useful and don't seem to cause any complaints. Finally, there is the last thorny issue, which is the default init system. There have apparently been strong representations at recent conference meetings for systemd to be the default. I wasn't there but I have had this conversation a few times in various forums and the request isn't new. Personally, I've had concerns for a few reasons: a) systemd is not well supported on some of our key supported targets (e.g. musl). I appreciate that is changing, we're not there yet though. b) systemd has a habit of unilaterally imposing constraints on their target systems for things like file system layouts. I don't think the project should be working that way and I don't think OE should be beholden to that given our own philosophy of allowing customisation. c) the amount of work involved in switching d) the reality that it is mostly a perception thing, you can select whichever init system you want really easily so the default doesn't matter that much in reality. It is really easy to say "of course it should be the default". The practicalities of changing it are pretty nasty. Somehow you need to explain to the existing user base about the change, and how they update their configs so they can continue to get what they need. Someone needs to document that and we also need people to handle the confused users appearing on mailing lists, on IRC and so on. >From a personal perspective, someone would effectively need to invert the test matrix in poky's CI setup, ensuring everything still gets covered. There are "small" details like the churn in test result reports where nothing will match over the transition point. The TSC has basically said "we need to do it". The TSC does not have resources, they just want me to go ahead and make it happen somehow. I'm personally really tired of fighting this kind of thing. As such, I may well just end up taking the two weeks it probably needs to go and try and make it happen as best I can. This will impact patch review, autobuilder stability and a ton of other things, but if this is what the community wants and demands, I'm not sure I can fight it. Honestly, I really don't need this, I'm burnt out and have had enough. I don't think I can fight off a OE board level push to make the change though against the feedback of "this is what the community is asking for". So, we have three sets of proposed changes and I wanted to put these onto the architecture list ASAP for feedback. I will probably work on some of the patches in parallel to the discussion, just so we can understand if there are any unforeseen issues with some of the changes. Personally, I think the first two sets are probably long overdue but my reluctance on the first should be clear. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2260): https://lists.openembedded.org/g/openembedded-architecture/message/2260 Mute This Topic: https://lists.openembedded.org/mt/117872790/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
