Yocto Project Discussions
 help / color / mirror / Atom feed
From: "Aleksandar Nikolic" <aleksandar.nikolic010@gmail.com>
To: "Dmitry Baryshkov" <dbaryshkov@gmail.com>, yocto@lists.yoctoproject.org
Subject: Re: [yocto] Yocto Binary Distro
Date: Mon, 07 Oct 2024 13:34:16 -0700	[thread overview]
Message-ID: <16147.1728333256445916327@lists.yoctoproject.org> (raw)
In-Reply-To: <CALT56yPtvqV-nOv931v7ZTR5T+3+szG_FG6GUuDfpruQGgMBAQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2695 bytes --]

Hi,

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, 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@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).

Aleksandar

> 
> --
> With best wishes
> Dmitry

[-- Attachment #2: Type: text/html, Size: 3690 bytes --]

  reply	other threads:[~2024-10-07 20:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-07  5:03 Yocto Binary Distro Aleksandar Nikolic
2024-10-07 11:31 ` [yocto] " Alexander Kanavin
2024-10-07 14:43   ` Aleksandar Nikolic
2024-10-07 19:07   ` Dmitry Baryshkov
2024-10-07 19:27     ` Alexander Kanavin
2024-10-07 19:29       ` Dmitry Baryshkov
2024-10-07 20:34         ` Aleksandar Nikolic [this message]
2024-10-07 23:25           ` Dmitry Baryshkov
2024-10-08  8:30             ` Aleksandar Nikolic
2024-10-08  8:53               ` Mikko Rapeli
2024-10-08 12:09                 ` Aleksandar Nikolic
2024-10-08 12:16                   ` Mikko Rapeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16147.1728333256445916327@lists.yoctoproject.org \
    --to=aleksandar.nikolic010@gmail.com \
    --cc=dbaryshkov@gmail.com \
    --cc=yocto@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox