1、要添加新計算機，您需要將新機器配置文件添加到圖層的 conf/machine目錄。此配置文件提供有關要添加的設備的詳細信息。
2、OpenEmbedded構建系統使用機器機配置文件的根名稱來引用新機器。
例如，一個給定的機器配置文件 crownbay.conf，構建系統會將機器識別為“crownbay”。
3、必須在機器配置文件中設置或必須從其他較低級別的配置文件中包含的最重要的幾個變量
TARGET_ARCH (e.g. "arm") PREFERRED_PROVIDER_virtual/kernel MACHINE_FEATURES (e.g. "apm screen wifi")
4、這幾個變量也可能是需要的
SERIAL_CONSOLES (e.g. "115200;ttyS0 115200;ttyS1") KERNEL_IMAGETYPE (e.g. "zImage") MAGE_FSTYPES (e.g. "tar.gz jffs2")
一個例子：
meta-yocto-bsp/conf/machine/beagblone-yocto.conf
5、如果要創建新的內核菜譜，則通常的菜譜編寫規則也適用於設置 SRC_URI。因此，您需要指定必要的補丁程序，並設置 S 為指向源代碼。您需要創建一個do_configure任務，該任務使用defconfig文件配置內核 。
您可以通過使用make defconfig 命令來執行此操作，或更常見的做法是，復制合適的 defconfig文件，然后運行 make oldconfig。
通過利用inherit kernel和其他一些linux-*.inc 文件，大多數其他功能都被集中，該類的默認設置通常可以正常運行。
6、如果要擴展現有的內核菜譜，通常只需添加合適的defconfig 文件即可。該文件需要添加到與給定內核配方中其他機器所用defconfig文件類似的位置 。
可能的方法是在SRC_URI中列出文件，並將機器添加到COMPATIBLE_MACHINE中的表達式中 ：
COMPATIBLE_MACHINE = '(qemux86|qemumips)'
7、添加一個Formfactor配置文件，主要是硬盤配置信息，需要人工確定的信息
7.1、formfactor配置文件提供有關正在為其生成映像的目標硬件的信息，以及生成系統無法從內核等其他源獲取的信息。
7.2、ormfactor配置文件中包含的一些信息示例包括幀緩沖區方向、系統是否具有鍵盤、鍵盤相對於屏幕的位置以及屏幕分辨率
7.3、在大多數情況下，構建系統使用合理的默認值。但是，如果需要自定義，則需要在meta/recipes-bsp/formfactor/files 目錄中創建一個machconfig文件
7.4、該目錄包含特定計算機的目錄，例如 qemuarm和qemux86。有關可用設置和默認設置的信息，請參見meta/recipes-bsp/formfactor/files/config同一區域中找到的 文件。
以下是“ qemuarm”計算機的示例：
HAVE_TOUCHSCREEN = 1
HAVE_KEYBOARD = 1
DISPLAY_CAN_ROTATE = 0
DISPLAY_ORIENTATION = 0
＃DISPLAY_WIDTH_PIXELS = 640
＃DISPLAY_HEIGHT_PIXELS = 480
＃DISPLAY_BPP = 16
DISPLAY_DPI = 150
DISPLAY_SUBPIXEL_ORDER = vrgb
8、升級菜譜
有3種方式升級菜譜
1、自動升級幫助器（AUH）設置自動版本升級
2、使用devtool upgrade 來設置半自動版本升級
3、通過手動編輯菜譜來升級配方
8.1、使用自動升級助手（AUH）
AUH實用程序與OpenEmbedded構建系統結合使用，以便根據上游發布的新版本自動生成配方升級。
以下步驟描述了如何設置AUH實用程序
1、如果您沒有配置用戶和電子郵件，則可以使用以下命令進行配置
$ git config --global user.name some_name
$ git config --global user.email username@ domain.com
2、要使用AUH，必須將存儲庫克隆到開發主機上
AUH不屬於OpenEmbedded-Core (OE-Core) 和Poky存儲庫
$ git clone git://git.yoctoproject.org/auto-upgrade-helper
Cloning into 'auto-upgrade-helper'...
remote: Counting objects: 768, done.
remote: Compressing objects: 100% (300/300), done.
remote: Total 768 (delta 499), reused 703 (delta 434)
Receiving objects: 100% (768/768), 191.47 KiB | 98.00 KiB/s, done.
Resolving deltas: 100% (499/499), done.
Checking connectivity... done.
3、創建專用的構建目錄
運行 oe-init-build-env 腳本以創建專門用於運行AUH實用程序的新的構建目錄
不要使用現有的構建目錄及其配置，因為現有的設置可能會導致AUH失敗或出現不良行為
$ cd ~/poky
$ source oe-init-build-env your_AUH_build_directory
4、在local.conf文件中進行配置，在剛為AUH創建的構建目錄中的local.conf文件中需要存在一些設置
a、如果要啟用 Build History（可選），則conf/local.conf文件中需要以下幾行 ：
INHERIT =+ "buildhistory"
BUILDHISTORY_COMMIT = "1"
使用此配置並成功升級后，構建歷史記錄"diff"文件將出現在構建目錄中的upgradehelper/work/recipe/buildhistory-diff.txt文件中.。
b、如果要通過testimage 可選的類啟用測試 ，則需要在conf/local.conf文件中進行以下設置
INHERIT += "testimage"
如果您的發行版默認不啟用ptest(而Poky啟用)，則您在local.conf文件中需要以下內容:
DISTRO_FEATURES_append = " ptest"
5、可選）啟動vncserver： 如果您在沒有X11會話的服務器中運行，則需要啟動vncserver：
$ vncserver :1
$ export DISPLAY=:1
6、創建和編輯AUH配置文件
您需要在構建目錄中擁有upgrade-helper/upgrade-helper.conf 配置文件。您可以在 AUH源存儲庫中找到樣本配置文件 。
通讀樣本文件並根據需要進行配置。例如，如果您在前面所述的 local.conf中啟用了構建歷史記錄，則必須在upgrade-helper.conf中啟用它.。
另外，如果您使用的是Poky附帶的且位於meta-yocto中的默認maintainers.inc文件， 並且未在upgrade-helper.conf配置中設置
"maintainers_whitelist"或"global_maintainer_override"，並且在AUH命令行上指定了"-e all"，該實用程序會自動向所有默認維
護者發送電子郵件。請避免這種情況.
8.1.1 如何使用AUH：
1、升級特定菜譜
$ upgrade-helper.py recipe_name
例如：升級xmodmap菜譜 $ upgrade-helper.py xmodmap
2、將特定食譜升級到特定版本
$ upgrade-helper.py recipe_name-tversion
例如，此命令將xmodmap配方升級 到版本1.2.3：
$ upgrade-helper.py xmodmap -t 1.2.3
3、將所有食譜升級到最新版本並取消電子郵件通知
$ upgrade-helper.py all
運行AUH實用程序后，您可以在AUH構建目錄中找到結果：
${BUILDDIR}/upgrade-helper/timestamp
4、AUH實用程序還會根據層樹中成功的升級嘗試來創建菜譜更新提交
8.2、使用devtool upgrade
1、要查看devtool upgrade可用的所有命令行選項， 請使用以下幫助命令:
$ devtool upgrade -h
2、如果要查找菜譜當前在上游的版本，而又不升級菜譜的本地版本，則可以使用以下命令：
$ devtool latest-version recipe_name
3、devtool升級工作的自動化程度低於AUH。
具體而言， devtool upgrade僅可在單個命名的菜譜上運行，無法使用鏡像執行構建和集成測試，並且不會自動為源樹中的更改生成提交.。
4、將本地存儲庫中2.7.4版本升級到2.9.3
devtool upgrade nano -V 2.9.3
如果不使用 -V 選項，會將菜譜升級到最新版本
5、使用devtool build來構建升級后的菜譜
$ devtool build nano
6、在devtool upgrade工作流程中，存在部署和測試重建軟件的機會。但是，對於此示例，一旦工作空間中的源是干凈的，就會運行 devtool finish清理工作空間
一旦tree是干凈的，您可以使用以下命令從${BUILDDIR}/workspace/sources/nano目錄中清除以下示例中的內容
$ devtool finish nano meta-oe
使用該devtool finish命令清理工作空間並根據您的提交創建補丁文件。該工具將所有補丁文件放回到nano在這種情況下命名的子目錄的源目錄中。
8.3、手動升級菜譜
手動更新多個菜譜的擴展性很差，涉及許多步驟。升級菜譜版本的建議是通過AUH或devtool升級
手動升級的步驟：
1、更改版本：
重命名菜譜，以使版本(即菜譜名稱的PV)適當更改。如果版本不是菜譜名稱的一部分，請更改菜譜本身中PV設置的值 。
2、更新SRCREV（如果需要）：
如果從Git或其他版本控制系統中獲取了配方構建的源代碼，請進行更新 SRCREV 以指向提交的與新版本相匹配的哈希值。
3、編譯軟件：
嘗試使用BitBake生成菜譜。典型的編譯失敗情況包含以下幾個方面：
3.1、許可聲明已針對新版本進行了更新。
對於這種情況，您需要檢查對許可證的任何更改，並根據需要更新LICENSE和LIC_FILES_CHKSUM的值.。
3.2、菜譜的舊版本附帶的自定義補丁可能無法應用於新版本。
對於這些情況，您需要檢查失敗。如果升級版本已解決了這些問題，則對於新版本的軟件而言，可能不需要補丁程序。
如果需要補丁程序且該打補丁失敗，則需要將其重新設置為新版本.。
3.3、嘗試構建多個架構（可選）：
一旦為給定體系結構成功構建了新軟件，就可以通過更改MACHINE變量並重新構建軟件來測試其他體系結構的構建.如果要公開發布菜譜，則此可選步驟特別重要.。
3.4、查看上游的變更日志和發行說明：
檢查這兩項，可以發現是否存在可能破壞向后兼容性的新功能。如果是這樣，您需要采取措施緩解或消除這種情況。
3.5、創建可引導映像並測試 （可選）：
如果需要，可以通過將新軟件引導到實際硬件上來對其進行測試.
3.6、為layer存儲庫中的更改創建提交：
在所有構建工作完成並且任何測試成功之后，您可以為保存升級菜譜的layer中的任何更改創建提交.。
8.4、查找臨時源代碼
您可能會發現在開發過程中修改菜譜用來構建軟件包的臨時源代碼很有用。
例如，您正在開發補丁程序，則需要進行一些試驗以找出解決方案。最初構建軟件包之后，可以迭代地調整Build Directory中的源代碼， 然后可以強制重新編譯並快速測試更改后的代碼。
確定解決方案后，即可以補丁程序的形式保留更改。
在構建過程中，由S變量定義的Build Directory中提供了菜譜用來構建軟件包的解壓的臨時源代碼。
下面是源目錄中meta/conf/bitbake.conf配置文件中定義的S變量的默認值:
S = "${WORKDIR}/${BP}"
您應該注意，許多菜譜都覆蓋了S變量 ，從Git獲取其來源的菜譜通常將S設置為${WORKDIR}/git.。
BP表示基本菜譜名稱，由名稱和版本組成:
BP = "${BPN}-${PV}"
菜譜工作目錄(WORKDIR)的路徑定義如下:
${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
實際目錄取決於幾個事情：
TMPDIR：頂級構建輸出目錄。 MULTIMACH_TARGET_SYS：目標系統標識符。 PN：菜譜名稱。 EXTENDPE：（如果 PE 未指定，大多數食譜通常如此，EXTENDPE則為空白）。 PV：菜譜版本。 PR：菜譜修訂版本。
例如，假設有一個源目錄的頂級文件夾名為poky，一個默認的構建目錄poky/build，和一個qemux86-poky-linux目標機器系統。另外假設你的菜譜名稱為foo_1.3.0.bb
在這種情況下，構建系統用於構建軟件包的工作目錄如下：
poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
8.5、在工作流中使用Quilt
Quilt 是一個功能強大的工具，可讓您無需干凈的源代碼樹即可捕獲源代碼更改。本節概述了可用於修改源代碼，測試更改，然后將更改以補丁程序的形式全部使用Quilt保留的典型工作流程。
注意：關於保留對源文件的更改，如果您清除了菜譜或啟用了rm_work，則Yocto項目應用程序開發和可擴展軟件開發中所述的devtool工作流與使用Quilt的流程相比， Kit(eSDK)手冊是更安全的開發流程.
使用Quilt的步驟：
8.5.1、查找源代碼
OpenEmbedded構建系統使用的臨時源代碼保存在 構建目錄中
8.5.2、更改工作目錄：
您需要位於具有臨時源代碼的目錄中。該目錄由S 變量定義 。
8.5.3、創建一個新補丁：
在修改源代碼之前，您需要創建一個新補丁。要創建新的補丁文件，請按以下方式使用quilt new ：
$ quilt new my_changes.patch
8.5.4、通知quit並添加文件
創建補丁后，您需要將計划編輯的文件通知Quilt.您可以通過將文件添加到剛創建的補丁中來通知Quilt
$ quilt add file1.c file2.c file3.c
8.5.5、編輯文件
在源代碼中對添加到補丁中的文件進行更改.。
8.5.6、測試更改
修改源代碼后，測試更改的最簡單方法是調用do_compile任務， 如以下示例所示:
$ bitbake -c compile -f package
-f 或 --force屬性強制執行指定的任務。如果您發現代碼有問題，則可以繼續進行迭代編輯和重新測試，直到一切正常為止
使用BitBake 運行do_clean 或 do_cleanall任務（即 bitbake -c clean package 和 bitbake -c cleanall package）后，您對臨時源代碼所做的所有修改都會消失 。
如果您使用“ 構建期間節省磁盤空間 ”部分中所述的rm_work功能，修改也將消失 。
8.5.7、生成補丁
一旦更改按預期進行，您需要使用Quilt生成包含所有修改的最終補丁.
$ quilt refresh
到這里，這個my_changes.patch補丁文件，具有file1.c， file2.c和file3.c 所有更改，您可以在源(S)目錄的patch/子目錄中找到生成的補丁文件 。
8.5.8、復制補丁文件
為簡單起見，請將補丁文件復制到名為files的目錄中，您可以在包含菜譜(.bb)文件或追加(.bbappend)文件的目錄中創建該目錄。
在此處放置補丁程序可以確保OpenEmbedded構建系統可以找到該補丁程序。接下來，將補丁添加到菜譜的SRC_URI中。
這是一個例子：
SRC_URI += "file://my_changes.patch"
8.6、生成簡單映像
8.6.1、構建一個init RAM 文件系統（initramfs）
1、創建initramfs映像菜譜
可以引用在源目錄的meta/recipes-core目錄中找到的core-image-minimal-initramfs.bb菜譜作為例子。
2、確定是否需要將initramfs映像捆綁到內核映像中
如果您希望將內置的initramfs映像與內核映像捆綁在一起，請在local.conf文件中，將INITRAMFS_IMAGE_BUNDLE變量設置為"1"，並設置用於構建內核映像的菜譜中的INITRAMFS_IMAGE變量.。
建議將它與內核鏡像進行綁定，以減少依賴
3、設置INITRAMFS_IMAGE_BUNDLE標志會使initramfs映像解壓縮到${B}/usr/目錄中。然后使用CONFIG_INITRAMFS_SOURCE
變量將解壓縮后的initramfs映像傳遞到內核的Makefile，從而可以將initramfs映像正常地構建到內核中。
4、如果選擇不將initramfs映像與內核映像捆綁在一起，則實際上是在使用 Initial RAM Disk（initrd）。
創建initrd主要是通過處理 INITRD_IMAGE， INITRD_LIVE和 INITRD_IMAGE_LIVE變量。有關更多信息，請參見 image-live.bbclass 文件。
5、(可選)通過initramfs鏡像菜譜將項目添加到initramfs鏡像
如果通過菜譜將項目添加到initramfs鏡像，則應使用 PACKAGE_INSTALL 而不是 IMAGE_INSTALL。
您可能不希望由image 或 core-image 類來設置默認值，PACKAGE_INSTALL可以更直接地控制添加到圖像的內容
6、生成內核映像和initramfs映像
使用BitBake生成內核映像。由於initramfs映像菜譜是內核映像的依賴項，因此，如果您使用了前面介紹的INITRAMFS_IMAGE_BUNDLE 變量，則也將構建initramfs映像並將其與內核映像捆綁在一起 。
8.6.2、構建一個微型系統（Tiny System）
1、為了幫助您查看當前內核和根文件系統大小的位置，可以使用在scripts/tiny/目錄中找到的兩個工具:
ksize.py: 報告內核構建對象的組件大小.
dirsize.py: 報告根文件系統的組件大小.
2、下一個工具和命令可幫助您組織配置片段並以易於理解的形式查看文件依賴性:
merge_config.sh：幫助您管理內核中的配置文件和片段。
使用此工具，您可以將各個配置片段合並在一起。該工具允許您進行覆蓋並警告您缺少任何配置選項。該工具非常適合允許您迭代配置，創建最少的配置以及為不同機器創建配置文件，而不必重復您的過程。
該merge_config.sh腳本是Linux內核Yocto Git代碼庫中scripts/kconfig目錄的一部分（例如：linux-yocto-3.14， linux-yocto-3.10， linux-yocto-3.8，等等）。
3、bitbake -u taskexp -g ：bitbake_target
將BitBake命令與這些選項一起使用會打開一個依賴關系管理器，您可以從中查看文件依賴關系。了解這些依賴關系后，您可以在裁剪內核和根文件系統的各個部分時做出明智的決定。
8.7、從外部源構建軟件 ，使用自己定制的內核或uboot
假設您有一個項目，其中包含帶有高度自定義內核的新BSP。而且，暴露給開發團隊盡量小的特性，以便他們可以專注於自己的項目並盡可能維護每個人的工作流程.
在這種情況下，您需要在開發機器上進行開發的內核源目錄。您希望菜譜的SRC_URI變量指向外部目錄並按原樣使有用，而不是復制它.。
要使用來自外部源的軟件進行構建，您需要做的就是繼承externalsrc類，然后將EXTERNALSRC變量設置為指向您的外部源代碼。
以下是在local.conf文件中添加的語句
INHERIT += "externalsrc"
EXTERNALSRC_pn-myrecipe = "path-to-your-source-tree"
下一個示例顯示如何通過EXTERNALSRC在配方本身或配方的附加文件中進行設置來完成相同的操作：
EXTERNALSRC = "path"
EXTERNALSRC_BUILD = "path"
為了使這些設置生效，您必須全局或本地繼承externalsrc類
默認情況下，externalsrc.bbclass在與EXTERNALSRC指定的外部源目錄不同的目錄中構建源代碼。
如果需要在與源相同的目錄或其他指定目錄中構建源，則可以將EXTERNALSRC_BUILD設置為指向該目錄：
EXTERNALSRC_BUILD_pn-myrecipe = "path-to-your-source-tree"
8.8、離線構建
為構建中使用的上游源創建一個"snapshot"，然后在以后使用該"snapshot"脫機復制構建，這是非常有用的
您需要先准備並填充文件"快照"的下載目錄
下載目錄准備就緒后，您可以隨時在任何計算機上使用它來復制您的構建。
請按照以下步驟來填充您的下載目錄。
1、創建一個干凈的下載目錄
DL_DIR設置為指向空位置或尚不存在的位置
2、從git源生成tarball
DL_DIR = "/home/your-download-dir/"
BB_GENERATE_MIRROR_TARBALLS = "1"
3、填充下載目錄，不執行構建
$ bitbake target --runonly=fetch
一旦下載目錄包含了與源文件有關的所有內容，就可以創建“自己的鏡像”並建立目標
請按照以下步驟使用下載目錄中的文件來構建目標：
1、僅使用本地文件
在local.conf文件內部，添加 SOURCE_MIRROR_URL 變量，繼承own-mirrors 類，然后將 BB_NO_NETWORK 變量用於local.conf。
SOURCE_MIRROR_URL ?= "file:///home/your-download-dir/"
INHERIT += "own-mirrors"
BB_NO_NETWORK = "1"
SOURCE_MIRROR_URL和 own-mirror類設置系統使用的下載目錄為“own mirror”。使用BB_NO_NETWORK 變量可確保BitBake在步驟3中的提取過程保持本地狀態，這意味着將使用“own mirror”中的文件。
2、從干凈的環境構建
可以刪除${TMPDIR}目錄或者使用一個新的Build目錄
3、構建目標
$ bitbake target
使用已知的鏡像源文件的本地"snapshot"來完成構建。源文件"snapshot"的最終壓縮包位於downloads目錄中
注意：如果菜譜通過將SRCREV設置為${AUTOREV}來嘗試查找軟件的最新版本，則離線構建將不起作用
SRCREV = "${AUTOREV}"
當菜譜將SRCREV設置為${AUTOREV}時，構建系統將訪問網絡以嘗試確定SCM中軟件的最新版本。通常使用AUTOREV的菜譜是自定義或修改的recipes.駐留在公共存儲庫中的菜譜通常不使用AUTOREV.
4、如果你確實有菜譜使用AUTOREV，那么你可以采取如下步驟來以離線方式來構建該菜譜
1、使能歷史記錄
2、使用buildhistory-collect-srcrevs命令從構建歷史記錄中收集存儲的SRCREV值
3、一旦有了正確的源修訂版，就可以修改這些菜譜以將SRCREV設置為軟件的特定版本.
8.9、提高構建速度
BB_NUMBER_THREADS: BitBake同時執行的最大線程數. BB_NUMBER_PARSE_THREADS: BitBake在解析過程中使用的線程數. PARALLEL_MAKE: 在do_compile任務期間將附加選項傳遞給make命令， 以便在本地構建主機上指定並行編譯. PARALLEL_MAKEINST: 在do_compile任務期間將附加選項傳遞給make命令， 以便在本地構建主機上指定並行安裝.
9.0、使用庫
1、包含靜態庫文件
meta/conf/bitbake.conf配置文件中的PACKAGES和FILES_*變量定義如何打包do_install任務安裝的文件。
默認情況下， PACKAGES變量包含${PN}-staticdev，它代表所有靜態庫文件.。
下面是meta/conf/bitbake.conf文件內容，里面可以看見PACKAGES的配置包含了${PN}-staticdev
PACKAGE_BEFORE_PN ?= ""
PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
PACKAGES_DYNAMIC = "^${PN}-locale-.*"
FILES = ""
FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
${sysconfdir} ${sharedstatedir} ${localstatedir} \
${base_bindir}/* ${base_sbindir}/* \
${base_libdir}/*${SOLIBS} \
${base_prefix}/lib/udev/rules.d ${prefix}/lib/udev/rules.d \
${datadir}/${BPN} ${libdir}/${BPN}/* \
${datadir}/pixmaps ${datadir}/applications \
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
${libdir}/bonobo/servers"
FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
${datadir}/gnome/help"
SECTION_${PN}-doc = "doc"
FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}"
FILES_${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
${datadir}/aclocal ${base_libdir}/*.o \
${libdir}/${BPN}/*.la ${base_libdir}/*.la"
SECTION_${PN}-dev = "devel"
ALLOW_EMPTY_${PN}-dev = "1"
RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a ${libdir}/${BPN}/*.a"
SECTION_${PN}-staticdev = "devel"
RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
9.1、將多個版本的庫文件合並到一個映像中
構建系統提供能夠使用不同的目標優化選項或體系架構構建庫，並將它們組合在一起成為一個系統映像。您可以根據特定用例的需要，將映像中的不同二進制文件鏈接到不同的庫.此功能稱為"Multilib".
雖然Multilib功能最常用於32位和64位差異，但是構建系統使用的方法有助於實現不同的目標優化選項。
您可以編譯一些二進制文件以使用一組庫，而另一些二進制文件以使用另一組庫。這些庫在體系結構，編譯器選項或其他優化方面可能有所不同。
源目錄中的meta-skeleton層中有幾個示例:
conf/multilib-example.conf 配置文件
conf/multilib-example2.conf 配置文件
recipes-multilib/images/core-image-multilib-example.bb 菜譜
9.2、准備使用Multilib
為了啟用Multilib，首先需要確保您的菜譜已擴展為支持多個庫。許多標准配方已經擴展，並且支持多個庫。您可以查看meta/conf/multilib.conf 配置文件， 以查看如何使用BBCLASSEXTEND 變量完成此操作 。
最終，所有菜譜都將涵蓋在內，並且不需要此列表。
在大多數情況下，Multilib類擴展會自動將包名稱從${PN}擴展到 ${MLPREFIX}${PN}，其中MLPREFIX 是特定的multilib標准變量（例如“ lib32-”或“ lib64-”）。
例如 DEPENDS， RDEPENDS， RPROVIDES， RRECOMMENDS， PACKAGES，和 PACKAGES_DYNAMIC 被由系統自動擴展。
如果要手動擴展菜譜中的任何代碼，則可以使用 ${MLPREFIX}變量以確保正確擴展這些名稱。此自動擴展代碼位於中multilib.bbclass。
9.3、使用Multilib
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
IMAGE_INSTALL_append = " lib32-glib-2.0"
此示例在常規目標軟件包旁邊啟用了一個名為lib32的附加庫。當組合這些"lib32"替代方案時，該示例使用"x86"進行調整.
有關此特定調優的信息，請參見meta/conf/machine/include/ia32/arch-ia32.inc.
然后，該示例在所有鏡像中都包含lib32-glib-2.0，它說明了一種包含多庫依賴項的方法.您可以使用常規鏡像構建來包含此依賴關系，例如:
$ bitbake core-image-sato
您還可以使用以下命令專門構建Multilib軟件包:
$ bitbake lib32-glib-2.0
9.4、使用外部工具鏈
您可能需要在開發過程中使用外部工具鏈。在這種情況下，您需要完成的基本步驟如下：
-
了解已安裝的工具鏈所在的位置。對於需要構建外部工具鏈的情況，您需要采取單獨的步驟來構建和安裝工具鏈。
-
確保
bblayers.conf通過BBLAYERS變量將包含工具鏈的圖層添加到文件中 。 -
將文件中的
EXTERNAL_TOOLCHAIN變量設置為local.conf安裝工具鏈的位置。
Yocto項目使用的外部工具鏈的一個很好的例子是Mentor Graphics®Sourcery G ++工具鏈。您可以在http://github.com/MentorEmbedded/meta-sourcery/的README文件里查看有關如何使用特定圖層的信息
9.5、使用Wic工具（這一章沒有看完，我跳過了，以后需要做鏡像時再來看）
您必須構建一些本地工具，這些本地工具可以在構建系統上運行:
$ bitbake parted-native dosfstools-native mtools-native
在IMAGE_FSTYPES 變量包含wic，在WKS_FILE中包含wic kickstart file的名稱
獲取幫助信息
$ wic -h
$ wic --help
$ wic help
例如，以下命令返回對write命令的幫助
$ wic help write
Wic還存在另一種幫助.您可以通過list命令獲得有關單個鏡像的幫助
$ wic list beaglebone-yocto help
9.6、創建自己的發行版
1、為您的新發行版創建一個 Layers
創建發行層，以便可以將您的元數據和代碼分開。強烈建議您創建並使用自己的層進行配置和編碼。與僅將配置放入local.conf 配置文件相比，使用您自己的層會在構建多個machine時更容易再現相同的構建配置
2、創建發行配置文件
需要在圖層的conf/distro目錄中創建發行配置文件。您需要使用您的發行名稱(例如mydistro.conf)對其進行命名.
您可以將配置文件的一部分拆分為包含文件，然后從分發配置文件中"require"它們。確保將包含文件放置在圖層的conf/distro/include目錄中.
您的配置文件需要設置以下必需的變量：
DISTRO_NAME
DISTRO_VERSION
這些以下變量是可選的，通常您可以從分發配置文件中進行設置:
DISTRO_FEATURES DISTRO_EXTRA_RDEPENDS DISTRO_EXTRA_RRECOMMENDS TCLIBC
3、提供其他變量
定義發行版需要的其他變量。您可以在local.conf文件中包含幾乎所有變量。
4、指向您的發行版配置文件
在構建目錄中的local.conf文件中， 將DISTRO變量設置為指向您發行版的配置文件。
例如，如果您的發行版的配置文件名為mydistro.conf，則指向它，如下所示:
DISTRO = "mydistro”
5、如有必要，請向該層添加更多內容 ，使用您的層來保存發行所需的其他信息
1、添加菜譜以安裝其他菜譜尚未安裝的特定於發行版的配置文件。如果現有菜譜包含特定於發行版的配置文件，則應為其添加一個附加文件（.bbappend） 2、添加任何特定於您的發行版的鏡像recipes。 3、為有商標的啟動畫面添加一個psplash append文件。有關附加文件的信息 4、添加任何其他附加文件以進行特定於各個菜譜的自定義更改
9.7、創建自定義模板配置目錄
OpenEmbedded構建系統使用環境變量TEMPLATECONF定位目錄，從該目錄中收集配置信息，最終將這些信息存儲在Build Directory conf目錄中。
默認情況下， TEMPLATECONF是在poky倉庫中的設置如下:
TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}
這是構建系統用來查找用於從中構建一些關鍵配置文件的模板的目錄。如果您查看此目錄，將看到bblayers.conf.sample，local.conf.sample和conf-notes.txt文件
構建系統使用這些文件來形成各自的bblayers.conf文件，local.conf文件， 並在運行安裝腳本時顯示BitBake目標的列表.
如果新的Build Directory中的配置要覆蓋這些默認配置文件，只需要在.templateconf文件中設置TEMPLATECONF變量， 這個變量位於頂級的源碼樹下面，是隱藏文件
查看模板文件內容：
這個文件指定了模板的路徑是在 meta-poky/conf下面，查看該路徑的內容
這里面的文件會生成構建系統的配置文件，例如、/build/conf/bblayer.conf和/build/conf/local.conf文件
一個特殊的文件，conf-notes.txt
這個文件是初始化構建環境腳本（oe-init-build-env ）時，Bitbake顯示的內容：
可以修改這個文件，來增加顯示的內容，例如我添加一個picohood字符
9.8、在構建期間節省磁盤空間
為了在構建期間節省磁盤空間，您可以將以下語句添加到項目的local.conf配置文件中
INHERIT += "rm_work"
創建菜譜后，添加此語句將刪除用於創建菜譜的工作目錄
9.9、使用包
1、從鏡像中排除軟件包
如果你想排除一些包，那么可以在local.conf中使用這些變量
BAD_RECOMMENDATIONS：使用此變量可以指定您不想安裝的“recommended-only”軟件包。 NO_RECOMMENDATIONS： 使用此變量可以防止安裝所有“recommended-only”軟件包。 PACKAGE_EXCLUDE注意： 使用此變量可以阻止安裝特定程序包，無論它們是否為“recommended-only”。您需要認識到，當阻止安裝已經安裝完成的軟件包需要依賴的軟件包時，構建過程可能會因錯誤而失敗。
2、增加軟件包的版本
為了了解二進制軟件包的版本控制，您需要考慮以下因素：
二進制軟件包：最終構建並安裝到映像中的二進制軟件包。
二進制程序包版本：二進制程序包版本由兩個組件組成-版本和修訂。
PV：菜譜版本。 PV表示要打包的軟件的版本。不要將PV與二進制軟件包版本混淆。
PR：菜譜修訂版本
SRCPV：OpenEmbedded構建系統使用此字符串來幫助定義PV 何時需要在其中包含源代碼修訂版的值
PR Service：一種基於網絡的服務，可自動幫助提供的軟件包與現有的軟件包管理器應用程序兼容，例如RPM，APT和OPKG。
3、每當二進制軟件包的內容更改時，二進制軟件包的版本就必須更改。更改二進制軟件包的版本是通過更改或調整PR或PV值來完成的。增加這些值發生兩種方法之一：
自動使用程序包修訂服務（PR服務）。
手動遞增PR或PV變量。
9.9.1、與PR服務一起使用
嘗試在元數據中維護修訂號容易出錯，不准確，並且會給人們提交菜譜帶來麻煩。相反， PR服務會自動生成越來越多的數字，尤其是修訂字段，該字段會刪除人為因素.
該Yocto計划使用變量以優先級遞減，以促進修訂編號的順序（即 PE， PV和 PR 分別對應時期，版本和修訂）
由於OpenEmbedded構建系統使用“ 簽名 ”，這對於給定構建是唯一的，因此構建系統知道何時重新生成軟件包。
給定任務的所有輸入均由簽名表示，簽名可以在不同時觸發重建。因此，構建系統本身不依賴 PR，PV以及 PE數字觸發重建。但是，簽名可用於生成這些值。
1、如實現的那樣，構建系統使用PR服務的值並附加形式".x"的值，因此r0成為r0.1， r0.2等
2、PR Service的最簡單形式是，它存在於構建軟件包摘要的單個主機開發系統中（構建系統）
您可以通過在構建目錄PRSERV_HOST 中的local.conf文件中 進行設置來啟用本地PR服務 ：
PRSERV_HOST = "localhost:0"
服務啟動后，程序包將自動獲得增加的PR值，BitBake將負責啟動和停止服務器。
3、如果您有一個更復雜的設置，其中多個主機開發系統針對一個公共的共享軟件包摘要而工作，那么您將運行一個PR Service，並將其連接到每個建築系統。
對於這種情況，您需要使用以下bitbake-prserv命令啟動PR Service ：
bitbake-prserv --host ip --port port --start
4、除了手動啟動該服務之外，您還需要更新每個建築系統的local.conf文件，以便每個系統指向服務器和端口。
還建議您使用構建歷史記錄，它將歷史記錄與運行PR Service的服務器一起添加到二進制軟件包版本中。要啟用構建歷史記錄，請將以下內容添加到每個構建系統的local.conf文件中：
# It is recommended to activate "buildhistory" for testing the PR service
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"
9.9.2、手動修改PR
9.9.3、自動增加軟件包版本號
1、在獲取存儲庫時， BitBake使用SRCREV變量來確定要從其構建的特定源代碼版本。
請將SRCREV變量設置為AUTOREV，以使OpenEmbedded構建系統自動使用軟件的最新版本:
SRCREV = "${AUTOREV}"
2、此外，您需要在PV中引用SRCPV，以便在源代碼的版本更改時自動更新版本。
這是一個示例
PV = "1.0+git${SRCPV}"
3、OpenEmbedded構建系統將替換 SRCPV為以下內容：
AUTOINC+source_code_revision
4、構建系統用數字替換了AUTOINC.使用的數字取決於PR Service的狀態:
1、如果啟用了PR Service，則構建系統將數字遞增，這與PR的行為類似 。此行為會導致線性增加軟件包版本，這是理想的。
這是一個例子：
hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk
hello-world-git_0.0+git1+dd2f5c3565-r0.0_armv7a-neon.ipk
2、如果未啟用PR Service，則生成系統將AUTOINC 占位符替換為零（即“ 0”）。由於包含了源版本，因此這會導致更改軟件包版本。但是，軟件包版本不會線性增加。
這是一個例子：
hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk
hello-world-git_0.0+git0+dd2f5c3565-r0.0_armv7a-neon.ipk
3、總之，為此， OpenEmbedded構建系統不跟蹤二進制軟件包版本的歷史記錄。
在這種情況下， AUTOINC與PR相當。如果未啟用PR服務器， 則僅將軟件包版本中的AUTOINC替換為"0"。如果啟用了PR服務器，則構建系統會跟蹤軟件包版本，並在軟件包修訂版更改時增加編號。
10.0、使用可選的軟件包
許多軟件將功能拆分為可選模塊(或插件)，並且所構建的插件可能取決於配置選項。為了避免重復確定菜譜中可用模塊的邏輯，或者避免必須手動打包每個模塊， OpenEmbedded構建系統提供了動態處理模塊打包的功能
要處理可選的模塊包裝，您需要做兩件事:
1、確保模塊包裝已實際完成.
2、確保您的菜譜滿足其他菜譜對可選模塊的任何依賴關系
10.0.1、確保模塊包裝已實際完成.
1、為確保實際完成模塊包裝，請在菜譜的populate_packages Python函數中使用do_split_packages函數。
do_split_packages函數搜索指定路徑下的文件或目錄模式，並通過將其附加到PACKAGES變量，並為FILES_packagename， RDEPENDS_packagename，DESCRIPTION_packagename等設置適當的值，
為找到的每個文件或目錄創建一個程序包。
這是來自lighttpd菜譜的示例:
python populate_packages_prepend () {
lighttpd_libdir = d.expand('${libdir}')
do_split_packages(d, lighttpd_libdir, '^mod_(.*)\.so$',
'lighttpd-module-%s', 'Lighttpd module for %s',
extra_depends='')
}
2、上面的示例在對do_split_packages的調用中指定了許多內容
1、你的菜譜通過do_install搜索安裝文件中的目錄
2、用於匹配該目錄中的模塊文件的正則表達式。在示例中，請注意括號()，該括號標記了應從中派生模塊名稱的表達式部分
3、用於包名稱的模式
4、每個包的說明
5、extra_depends的空字符串， 它禁用對lighttpd主軟件包的默認依賴關系
如果在${libdir}中找到了一個名為mod_alias.so的文件，則將為該文件創建一個名為lighttpd-module-alias的程序包，並將description設置為"Lighttpd module for alias".。
3、有關顯示如何使用do_split_packages的更多示例，請參見poky source存儲庫的meta/recipes-connectivity/connman/目錄中的connman.inc文件。您還可以在meta/classes/kernel.bbclass中找到示例
10.0.2、滿足依賴性
1、您可以通過使用PACKAGES_DYNAMIC變量來確保滿足這些依賴性。
這是繼續前面顯示的lighttpd菜譜的示例:
PACKAGES_DYNAMIC = "lighttpd-module-.*"
2、正則表達式中指定的名稱當然可以是任何東西。
在此示例中，它是lighttpd-module， 並且被指定為前綴，以確保在構建期間滿足以該前綴開頭的程序包名稱上的任何RDEPENDS和RRECOMMENDS。
如果您正在使用上一節中所述的do_split_packages，則您在PACKAGES_DYNAMIC中輸入的值應對應於do_split_packages調用中指定的名稱模式
11、運行時包管理
下面幾種情況，你希望使用運行時包管理
1、您想向部署的設備提供現場更新(例如安全更新).
2、您希望為設備上運行的一個或多個應用程序提供快速的開發周期.
3、您想在設備上臨時安裝各種應用程序的"調試"軟件包，以便通過允許訪問符號和源調試來大大改
4、您希望為設備部署更小的軟件包選擇，但允許進行現場更新以添加更大的選擇以進行自定義.
11.1、構建注意事項
1、您需要注意這些注意事項才能為運行時程序包管理提供支持
當BitBake生成軟件包時，它需要知道要使用哪種格式.
在您的配置中，您可以使用PACKAGE_CLASSES變量指定格式:
1、打開構建目錄中的local.conf文件(例如〜/poky/build/conf/local.conf)
2、選擇所需的包格式，如下所示：
PACKAGE_CLASSES ?= “package_packageformat”
其中packageformat可以是"ipk"， "rpm"， "deb"或"tar"，這是受支持的軟件包格式
3、構建完成后，您的軟件包將位於${TMPDIR}/deploy/packageformat目錄中。
例如，如果${TMPDIR}是tmp，而您選擇的包類型是RPM，則你的PRM包在tmp/deploy/rpm目錄里面
12、在構建過程中有效的獲取源文件
OpenEmbedded構建系統使用通過SRC_URI變量定位的源文件，使用BitBake構建內容時，操作的很大一部分是查找並下載所有源tarball
1、設置有效鏡像
Yocto Project構建中的一項重要工作就是簡單地下載所有源tarball。也許其他人建立了一個相當大的源tarball目錄。
如果是這樣，您可以通過在配置文件中添加語句來節省時間，以便構建過程在檢查Internet之前先檢查本地目錄中是否存在現有的tarball。
這是在local.conf文件中進行設置的有效方法 ：
SOURCE_MIRROR_URL ?= "file:///home/you/your-download-dir/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
# BB_NO_NETWORK = "1"
上面的例子中BB_GENERATE_MIRROR_TARBALLS變量使OpenEmbedded構建系統生成Git存儲庫的tarball並將其存儲在DL_DIR目錄中 ，也可以使用PREMIRRORS變量
2、獲取源文件並屏蔽構建
您可以使用另一種方法，在不構建的情況下預取所有源文件。這個方法可以解決所有下載問題，並最終將所有源文件收集到DL_DIR所在的build/downloads下載目錄中 。
使用以下BitBake命令格式來獲取所有必需的源，而無需開始構建：
$ bitbake -c target runall="fetch"
13、選擇Initialization Manager
1、使用SysVinit，則無需執行任何操作
2、使用systemd
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
3、您還可以防止SysVinit分發功能自動啟用，如下所示:
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
這樣做會刪除所有多余的SysVinit腳本，要從鏡像中完全刪除初始化腳本，請同時設置此變量:
VIRTUAL-RUNTIME_initscripts = ""
4、將systemd用作主映像，將SysVinit用作修復映像
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
14、選擇設備管理器
Yocto項目提供了多種管理設備管理器的方法（/dev）
1、持久性和預先填充/dev： 對於這種情況，/dev目錄是持久性的，並且在構建期間創建了所需的設備節點。 2、使用devtmpfs與設備管理器： 對於這種情況，該/dev目錄是由內核提供的作為內存文件系統，並在運行時由內核自動填充。設備節點的其他配置是通過用戶管理器（如udev或） 在用戶空間中完成的 busybox-mdev。
1、使用持久和預填充/dev
要將靜態方法用於設備填充，需要將USE_DEVFS 變量設置 為“ 0”，如下所示：
USE_DEVFS = "0"
在/dev目錄中的內容是在設備列表文件中定義的。IMAGE_DEVICE_TABLES變量定義要使用的設備列表，應在計算機或發行版配置文件中進行設置。
或者，您可以在local.conf配置文件中設置此變量，如果未定義IMAGE_DEVICE_TABLES變量， 則使用默認的device_table-minimal.txt:
IMAGE_DEVICE_TABLES = "device_table-mymachine.txt"
2、使用devtmpfs和設備管理器
要用動態方法來進行設備填充，您需要使用USE_DEVFS變量(並確保將USE_DEVFS變量設置為"1")
USE_DEVFS = "1"
使用這個設置，/dev/目錄的內容是有內核通過devtmpfs來填充的，在構建Linux內核時，請確保設置了相應的內核配置變量CONFIG_DEVTMPFS
3、要對設備節點進行更多控制，可以使用udev或 busybox-mdev之類的設備管理器。
您可以通過在machine 或distro 配置文件中定義VIRTUAL-RUNTIME_dev_manager變量來選擇設備管理器。或者，您可以在local.conf配置文件中設置此變量:
15、使用外部SCM
如果您正在處理從外部源代碼管理器（SCM）提取的菜譜，則可以讓OpenEmbedded構建系統注意到添加到SCM的新菜譜更改，然后構建依賴於新配方的結果包。
使用最新版本。這僅適用於可以從中獲取合理的修訂版本號的SCM。當前，您可以使用Apache Subversion（SVN），Git和Bazaar（BZR）存儲庫進行此操作。
1、要啟用此行為， 菜譜的PV需要引用SRCPV.這是一個示例:
PV = "1.2.3+git${SRCPV}"
2、然后，您可以將以下內容添加到您的 local.conf：
SRCREV_pn-PN = "${AUTOREV}"
3、PN 是將要啟用自動源版本更新的菜譜的名稱。
4、如果您不想更新本地配置文件，則可以直接在菜譜中添加以下內容以完成功能的啟用:
SRCREV = "${AUTOREV}"
5、Yocto項目提供了一個名為poky-bleeding的發行版，其配置文件包含以下行:
require conf/distro/include/poky-floating-revisions.inc
此行拉入列出的包含文件，該文件包含許多格式完全相同的行:
#SRCREV_pn-opkg-native ?= "${AUTOREV}"
#SRCREV_pn-opkg-sdk ?= "${AUTOREV}"
#SRCREV_pn-opkg ?= "${AUTOREV}"
#SRCREV_pn-opkg-utils-native ?= "${AUTOREV}"
#SRCREV_pn-opkg-utils ?= "${AUTOREV}"
SRCREV_pn-gconf-dbus ?= "${AUTOREV}"
SRCREV_pn-matchbox-common ?= "${AUTOREV}"
SRCREV_pn-matchbox-config-gtk ?= "${AUTOREV}"
SRCREV_pn-matchbox-desktop ?= "${AUTOREV}"
SRCREV_pn-matchbox-keyboard ?= "${AUTOREV}"
SRCREV_pn-matchbox-panel-2 ?= "${AUTOREV}"
SRCREV_pn-matchbox-themes-extra ?= "${AUTOREV}"
SRCREV_pn-matchbox-terminal ?= "${AUTOREV}"
SRCREV_pn-matchbox-wm ?= "${AUTOREV}"
SRCREV_pn-settings-daemon ?= "${AUTOREV}"
SRCREV_pn-screenshot ?= "${AUTOREV}"
這些行允許您嘗試構建一個發行版，該發行版跟蹤眾多軟件包的最新開發源。
PR：配方修訂
16、創建根文件系統
要創建只讀根文件系統，只需在映像中添加"read-only-rootfs"功能.在鏡像菜譜中或在"構建目錄"中找到的local.conf文件中使用以下任何
語句，都會導致構建系統創建只讀的根文件系統:
IMAGE_FEATURES = "read-only-rootfs" or EXTRA_IMAGE_FEATURES += "read-only-rootfs"
1、安裝后腳本
確保在主機系統上的構建過程中創建根文件系統時，可以運行已安裝到映像中的軟件包的所有安裝后(pkg_postinst)腳本，這非常重要 ，因為這些腳本無法在目標設備的首次引導期間運行 。啟用"read-only-rootfs"功能后，構建系統將在創建根文件系統期間進行檢查，以確保所有安裝后腳本均成功。如果在創建根文件系統后仍需要運行這些腳本中的任何一個，則構建將立即失敗。這些構建時檢查可確保構建失敗，而不是目標設備在其初始引導操作期間稍后失敗。
2、構建系統解壓后的安裝后腳本都是經過工程設計的， 因此它們可以在根文件系統創建期間運行。但是，如果創建並添加自定義腳本，則需要確保它們可以在此文件系統創建期間運行
以下是一些常見的問題，這些問題會阻止在根文件系統創建期間運行安裝后腳本:
1、在絕對路徑前不使用$D: 在創建根文件系統時， 構建系統會定義$D。此外，當腳本在目標設備上運行時， $D是空白。這意味着$D有兩個用途:確保路徑在主機環境和目標環境中均有效，以及檢查以確定哪個環境用作采取適當措施的方法。 2、嘗試運行特定於或依賴於目標體系結構的進程: 您可以通過使用在主機系統上運行的本地工具來完成這些嘗試，以完成相同的任務，或者通過在QEMU下運行這些進程，具有qemu_run_binary函數
3、啟用“只讀rootfs”功能后，目標在運行時嘗試寫入根文件系統的任何嘗試都會失敗。因此，您必須確保你給進程和應用程序配置了具有寫訪問權限的目錄（例如/tmp或/var/run） 。
17、啟用和禁用構建歷史記錄
默認情況下禁用構建歷史記錄。要啟用它，請添加以下INHERIT語句，並在構建目錄中的conf/local.conf文件末尾將BUILDHISTORY_COMMIT變量可以設置為"1"在構建目錄中的conf/local.conf文件末尾:：
INHERIT += "buildhistory" BUILDHISTORY_COMMIT = "1"
構建歷史記錄信息保存在BUILDHISTORY_DIR變量定義的構建目錄中的${TOPDIR}/buildhistory中.
每個程序包的歷史記錄都包含一個文本文件，該文件具有名稱/值對以及有關程序包的信息.例如， buildhistory/packages/i586-pokylinux/busybox/busybox/latest包含以下內容:
PV = 1.22.1 PR = r32 RPROVIDES = RDEPENDS = glibc (>= 2.20) update-alternatives-opkg RRECOMMENDS = busybox-syslog busybox-udhcpc update-rc.d PKGSIZE = 540168 FILES =/usr/bin/*/usr/sbin/*/usr/lib/busybox/*/usr/lib/lib*.so.*\ /etc/com/var/bin/*/sbin/*/lib/*.so.*/lib/udev/rules.d \ /usr/lib/udev/rules.d/usr/share/busybox/usr/lib/busybox/* \ /usr/share/pixmaps/usr/share/applications/usr/share/idl \ /usr/share/omf/usr/share/sounds/usr/lib/bonobo/servers FILELIST =/bin/busybox/bin/busybox.nosuid/bin/busybox.suid/bin/sh \ /etc/busybox.links.nosuid/etc/busybox.links.suid