From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17D3BCFB45D for ; Mon, 7 Oct 2024 20:34:19 +0000 (UTC) Subject: Re: [yocto] Yocto Binary Distro To: "Dmitry Baryshkov" , yocto@lists.yoctoproject.org From: "Aleksandar Nikolic" X-Originating-Location: Erlangen, Bavaria, DE (147.161.171.73) X-Originating-Platform: Windows Chrome 129 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Mon, 07 Oct 2024 13:34:16 -0700 References: In-Reply-To: Message-ID: <16147.1728333256445916327@lists.yoctoproject.org> Content-Type: multipart/alternative; boundary="hFKLrJj9M2VlMeQg3rVI" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Mon, 07 Oct 2024 20:34:19 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/yocto/message/63951 --hFKLrJj9M2VlMeQg3rVI Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I'll reply on the last message from Alex, but thanks Dmitry for your initia= l message and the story how we came from =C3=85ngr=C3=B6m to what we have n= ow. Also thanks to both of you for the extensive feedback! On Mon, Oct 7, 2024 at 09:29 PM, Dmitry Baryshkov wrote: >=20 > On Mon, 7 Oct 2024 at 21:27, Alexander Kanavin > wrote: >=20 >> On Mon, 7 Oct 2024 at 21:07, Dmitry Baryshkov >> wrote: >>=20 >>>=20 >>>> 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. >>>=20 >>>=20 >>=20 >> ... >>=20 >>=20 >>> 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. >>=20 >> 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. >=20 > Ugh, no, thank you. I also hate that idea. Yep, thanks for separating these two use cases. Regarding the former one (p= ulling a bunch of prebuilt binary packages from a server and assembling a t= arget 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 assura= nce for the QM team, it brings a hell lot of issues with it which are easil= y avoided by building from source. >=20 >=20 >> 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. >=20 > 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 th= e field with a package management system is however in my opinion a no-go (= from the reasons previously stated by all). Aleksandar >=20 > -- > With best wishes > Dmitry --hFKLrJj9M2VlMeQg3rVI Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi,
 
I'll reply on the last message from Alex, but thanks Dmitry for your i= nitial message and the story how we came from Ångröm t= o what we have now. Also thanks to both of you for the extensive feedback!<= /span>
 
On Mon, Oct 7, 2024 at 09:29 PM, Dmitry Baryshkov wrote:
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@gm= ail.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 w= ould
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 di= stro, I
think you'd better use some existing purposely binary distro (= like
Debian, Armbian or something from the RPM world). If you can affo= rd
having package management on the device, it's not tightly resource<= br />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
someh= ow pull a big pile of prebuilt binary packages from the net and
assemb= le 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 o= ne (pulling a bunch of prebuilt binary packages from a server and assemblin= g a target image out of them ), some coworkers want exactly this and I am t= rying to persuade them not to go down that path and just build from source.= IMHO, even though installing previously tested binaries might bring some a= ssurance 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 ta= rget
image with package management which feels like the traditional li= nux
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 th= e field with a package management system is however in my opinion a no-go (= from the reasons previously stated by all).
 
Aleksandar
--
With best wishes
Dmitry
--hFKLrJj9M2VlMeQg3rVI--