> Op 2 feb. 2026, om 00:35 heeft Richard Purdie > <[email protected]> het volgende geschreven: > > On Sat, 2026-01-31 at 15:49 +0100, Koen Kooi wrote: >>> Op 31 jan 2026 om 03:47 heeft hongxu via lists.openembedded.org >>> <[email protected]> het volgende >>> geschreven: >>> >>> On 1/31/26 00:56, Richard Purdie wrote: >>>> CAUTION: This email comes from a non Wind River email account! >>>> Do not click links or open attachments unless you recognize the >>>> sender and know the content is safe. >>>> >>>> Hi Hongxu, >>>> >>>>> On Fri, 2026-01-30 at 13:20 +0800, hongxu via >>>>> lists.openembedded.org wrote: >>>>> Would you please approve to add this layer to >>>>> https://git.yoctoproject.org/, I will maintain >>>>> meta-ollama for recipe uprev and bug fix >>>> Thanks for sharing this, it looks really interesting and I like >>>> the >>>> idea of it a lot. >> >> Great timing as well :) I’m currently at FOSDEM asking around how >> people would feel about a meta-ai layer that would have various bits >> in it: tflite, onnx-runtime, llama.cpp and other things that need >> compilation. >> >> At the OE BoF this morning I was pointed at this thread, so I’ll hook >> into that to ask: >> >> How would people feel about a layer that combines at least the >> runtimes and has active maintainers? >> >> The amount of ai/ml recipes I touch daily has grown too large to >> stuff in in the qcom-distro layer, but are also to spread out in >> other (vendor) layers to include by default. > > Keep in mind that putting all "AI" into one place might work out a bit > like putting all "python" or all "perl" recipes in one place has. We're > learning that may not be the best way to handle it.
Thankfully there are only a handful of runtimes currently :) > I do like the idea of small focused layers with an active maintainer > rather than something like meta-oe which becomes very hard to maintain > (or change). > > We could have a configuration which checked out and pulled together all > the different known 'AI' layers if that would be useful as a compromise > to make it more accessible/discoverable? > > If the tools to handle layers are the problem and putting people off > the smaller layers, we should fix that too… For me, it’s not the tooling per se, but for example onnx-runtime being in multiple layers, where the most sane one is a DISTRO layer from a silicon vendor. Its layer.conf drags would drag in way too many other layers and potentially be ‘unsafe’ due to override leakage, no YP compatible badge. And that’s just one recipe, pretty much all others share the same problem of having multiple layers providing a version. Regards, Koen
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2226): https://lists.openembedded.org/g/openembedded-architecture/message/2226 Mute This Topic: https://lists.openembedded.org/mt/117540395/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
