On Wed, 2026-02-18 at 10:58 +0000, Richard Purdie via lists.openembedded.org wrote: > 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.
These seem like sensible changes to make. > 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. This also makes sense to me. > 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". I'm concerned about the impact of this on your bandwidth and on the release schedule for the LTS. We are making good progress in recovering from the unfortunate number of simultaneous issues we faced in December/early January and we're working our way through the patch review backlog. That said, we still have outstanding issues which are blocking the 6.0 M2 build and we are working to a modified schedule for this release due to delays in the release of 5.3. We would normally be aiming to build M3 at the start of March, and that would be the point at which we would enter feature freeze. So, I would recommend that we push back on this if there is no other resource available to make the change and fully handle the impact on the autobuilder configuration, documentation, etc within the next couple of weeks. I do think that we should review the choice of default init manager - we can prioritise this after the LTS release is out. Best regards, -- Paul Barker
signature.asc
Description: This is a digitally signed message part
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2261): https://lists.openembedded.org/g/openembedded-architecture/message/2261 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]] -=-=-=-=-=-=-=-=-=-=-=-
