+1 Peter and Paul. It is too late to do this. Even if we could identify resources to do the work.
Walt Miner AGL Community Manager The Linux Foundation Visit us at: www.automotivegradelinux.org lists.automotivelinux.org www.linuxfoundation.org On Wed, Feb 18, 2026 at 9:22 AM Peter Kjellerstedt via lists.openembedded.org <[email protected]> wrote: > > -----Original Message----- > > From: [email protected] <openembedded- > > [email protected]> On Behalf Of Paul Barker > > Sent: den 18 februari 2026 13:15 > > To: [email protected]; openembedded-architecture > > <[email protected]> > > Subject: Re: [Openembedded-architecture] Proposed default distro setting > > changes > > > > 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 > > I'm with Paul here. Anything that jeopardizes the release schedule for the > LTS release should be reconsidered both two and three times. And IMHO, > this > is not something that needs to be handled before the release. It can wait. > > //Peter > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2268): https://lists.openembedded.org/g/openembedded-architecture/message/2268 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]] -=-=-=-=-=-=-=-=-=-=-=-
