mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-08 17:19:20 +00:00
Code Issues Projects Releases Wiki Activity

manuals: define proper numbered lists

Browse Source 
Using "#." instead of "1.", "2.", "3.", etc.

(From yocto-docs rev: 11c2585acd0fa6c330702af2359ce5a9e47cde1f)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reported-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker
2022-12-09 19:01:55 +01:00
committed by Richard Purdie
parent 474e071608
commit 6846d4d00b
28 changed files with 347 additions and 347 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/overview-manual/yp-intro.rst
+10 -10
View File
@@ -517,18 +517,18 @@ Historically, the Build Appliance was the second of three methods by
which you could use the Yocto Project on a system that was not native to
Linux.
1. *Hob:* Hob, which is now deprecated and is no longer available since
#. *Hob:* Hob, which is now deprecated and is no longer available since
the 2.1 release of the Yocto Project provided a rudimentary,
GUI-based interface to the Yocto Project. Toaster has fully replaced
Hob.
2. *Build Appliance:* Post Hob, the Build Appliance became available. It
#. *Build Appliance:* Post Hob, the Build Appliance became available. It
was never recommended that you use the Build Appliance as a
day-to-day production development environment with the Yocto Project.
Build Appliance was useful as a way to try out development in the
Yocto Project environment.
3. *CROPS:* The final and best solution available now for developing
#. *CROPS:* The final and best solution available now for developing
using the Yocto Project on a system not native to Linux is with
:ref:`CROPS <overview-manual/yp-intro:development tools>`.
@@ -719,27 +719,27 @@ workflow:
Following is a brief summary of the "workflow":
1. Developers specify architecture, policies, patches and configuration
#. Developers specify architecture, policies, patches and configuration
details.
2. The build system fetches and downloads the source code from the
#. The build system fetches and downloads the source code from the
specified location. The build system supports standard methods such
as tarballs or source code repositories systems such as Git.
3. Once source code is downloaded, the build system extracts the sources
#. Once source code is downloaded, the build system extracts the sources
into a local work area where patches are applied and common steps for
configuring and compiling the software are run.
4. The build system then installs the software into a temporary staging
#. The build system then installs the software into a temporary staging
area where the binary package format you select (DEB, RPM, or IPK) is
used to roll up the software.
5. Different QA and sanity checks run throughout entire build process.
#. Different QA and sanity checks run throughout entire build process.
6. After the binaries are created, the build system generates a binary
#. After the binaries are created, the build system generates a binary
package feed that is used to create the final root file image.
7. The build system generates the file system image and a customized
#. The build system generates the file system image and a customized
Extensible SDK (eSDK) for application development in parallel.
For a very detailed look at this workflow, see the