Many kinds to me.

Although I just maintain a few of small packages and only have a curiosity to this tools suddenly,  I got so many people serious answers.

Thanks again.

 

 

Warm regards

Jun Miao

 

From: Stephen Smoogen <ssmoogen@redhat.com>
Sent: Monday, July 17, 2023 7:21 PM
To: Development discussions related to Fedora <devel@lists.fedoraproject.org>
Cc: Miao, Jun <jun.miao@intel.com>
Subject: Re: [Question] how to make Fedora linux os ?

 

 

 

On Thu, 13 Jul 2023 at 21:45, Miao, Jun <jun.miao@intel.com> wrote:

Hi Guys,

 

AFAIK, the Yocto Project is an open source collaboration project that provides tools, templates, and methods to help developers create custom Linux-based systems for embedded devices.

 

My confusion is that:

  1. what`s the tool to make our Fedora Linux 38 released like Yocto?
  2. And Centos ?
  3. And Ubuntu ?

 

 

 

I believe the Yocto system is based on a similar system as Gentoo. It was chosen because most embedded teams at the time were fairly small (maybe 1-2 engineers per 'board') and setting up a multi-system pipeline was too much for getting a system which may only have a 'lifetime' of 1-2 years with a large amount of NDAs and other legal entanglements involved. It also came with the advantage that one could pick and choose layers to change overall design so a basic chipset could be found in a camera, phone, or washing machine but have different additions/subtractions done to make it work for each. As teams got larger, the tooling has become more complex so you can stand up dedicated build clusters and such but in general, a developer can figure out what will make something work themselves without bothering other developers.

 

My outsider look at Yocto OS development seems to have developers either focusing on specific problem sets: 'make this work on a refrigerator with this much memory/cpu/storage and these applications' or an overall 'layer' solution: 'Legal says no GPLv3 so please make sure none of them are included in an image' or 'we need to have one image with debug symbols and this debugger, and this image without', etc.

 

One problem with this style of development is that you can easily end up with 2 developers working on the same board but having chosen completely different optimizations and compile time choices that applications and libraries can not easily mix between the two.

 

The other operating systems you are looking at is aimed at a different problem where how do you get a large number of developers who may only focus on one bit be able to work with each other in a smooth as much manner. This means that the system is less about building the entire operating system in one location but more about makings sure that 400 developers can build stuff which will work together. This means that a developer builds only items which are for testing and developer, and then pushes changes to a central system which will attempt to rebuild things using choices (compiler options, disk layout, etc) set by either a Fedora Engineering Steering Committee decision or general agreement by the main maintainer of a subsystem. 

 

The Fedora and CentOS build systems are fairly complicated with about 70 to 100 interrelated applications from when a developer does a build to when someone can download a finished package on a mirror. I have tried writing out a 'map' like a subway system but I usually get lost somewhere in the middle.  The general solution is something like

 

[fedpkg] -> [Fedora Builders and Source Control] -> [Fedora QA] -> [Fedora Image Making (iso/containers/etc)] -> [Mirroring System] -> [User]

 

The above 'loses' a lot of granular tools in that set of items with various message buses, various side tools, etc.  The lost granularity covers various attempts to deal with concurrency problems where group A is updating the entire python stack while group B is still building updates based on the old stack.  Group A's work may take weeks so stopping group B during that time could lead to security issues. [There are many other concurrency which the community has found over the years but that was the first one which came to mind.]

 

--

Stephen Smoogen, Red Hat Automotive

Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren