I'll reply on the last message from Alex, but thanks Dmitry for your initial message and the story how we came from Ångröm to what we have now. Also thanks to both of you for the extensive feedback!

On Mon, 7 Oct 2024 at 21:27, Alexander Kanavin <alex.kanavin@gmail.com> wrote:

On Mon, 7 Oct 2024 at 21:07, Dmitry Baryshkov <dbaryshkov@gmail.com> wrote:

If you ask me, pulling pre-built packages into a yocto image is in
itself a horrible hack that goes against yocto philosophy, and I would
not want yocto to help that or support it in any way.

...

So, as much as I like OE, if you are thinking about a binary distro, I
think you'd better use some existing purposely binary distro (like
Debian, Armbian or something from the RPM world). If you can afford
having package management on the device, it's not tightly resource
constrained. And thus there is no need to go Yocto way.
I think we're talking about two different things here, so just in case
I'd clarify the difference. Point two is about using bitbake to
somehow pull a big pile of prebuilt binary packages from the net and
assemble a target image out of them. I don't like that at all.
Ugh, no, thank you. I also hate that idea.

Yep, thanks for separating these two use cases. Regarding the former one (pulling a bunch of prebuilt binary packages from a server and assembling a target image out of them ), some coworkers want exactly this and I am trying to persuade them not to go down that path and just build from source. IMHO, even though installing previously tested binaries might bring some assurance for the QM team, it brings a hell lot of issues with it which are easily avoided by building from source.

On the other hand having a yocto-based binary distro, e.g. a target
image with package management which feels like the traditional linux
distributions is fine with me. I'm not particularly interested in it,
and I'm also not sure it can work well, but people are welcome to work
on it if they find it interesting or useful.
Yep, I was thinking about the yocto-with-feeds.

Yes, I also think this use case makes more sense than the first one, but I also see it to be used during development only, so devs can install and use packages faster (than rebuilding the whole image). Updating a device in the field with a package management system is however in my opinion a no-go (from the reasons previously stated by all).