RFC-0271：錨定套件

問題陳述

目前，在 Fuchsia 中實作系統更新 (「OTA」) 時，需要同時儲存兩組完整的 Blob。這個方法很簡單，但如果裝置磁碟空間不足，就會造成問題。

摘要

這項 RFC 建議實作錨定套件，最初的說明請見 RFC-212。這些套件組合符合下列不變量：

• 系統更新 (OTA) 時，只會下載永久錨定的套件 (啟動檔案系統，根據 RFC-212 的 base)。
• 套件和 Blob 會以 Merkle 雜湊值做為專屬 ID。 對於自動錨定和隨選錨定套件，更新套件會包含攜帶這項資訊的 meta.far 封存雜湊。
• 系統套用更新並啟動新版系統後，系統會在某個時間點下載自動錨定和隨選錨定套件。
• 根據 RFC-145，前述要點與急切更新特別不一致，因為急切更新會對應至 自動、可升級和永久、可升級的套件集 (如 RFC-212 所述)：錨定套件不會將「正確」套件的驗證作業委派給其他方；急切更新允許套件獨立於系統 OTA 更新，而錨定套件則不允許。

不變量會對錨定套件集產生下列影響：

• 由於所有套件的加密雜湊仍會隨系統更新發布，因此必須執行系統更新，才能將這些套件更新至較新版本。
• 從應用程式的角度來看，套件是透過 OTA 發布還是以錨定套件形式發布，都無關緊要。不過，如果存取的功能是由尚未解析的套件提供，應用程式可能會出現延遲。詳情請參閱「效能」一節。
• 自動錨定套件不會隨選下載，這與工程建構中的 TUF 存放區套件和隨選錨定套件不同。而是在啟動更新後的系統時下載。

您可以運用自動錨定和隨選錨定套件，避免在裝置的非揮發性儲存空間中，於 OTA 期間將每個套件儲存兩次，進而提高儲存空間效率，尤其是在儲存空間受限的裝置上。

提振精神

目前，生產 Fuchsia 系統上常用的系統更新機制，會透過三分割區「ABR」架構執行完整更新。A 和 B 兩個分割區各包含一個完整的系統映像檔。R 分區包含最小復原分區，不在本 RFC 的範圍內。

在任何時間點，A 或 B 其中一個分割區都是有效分割區，也就是說，裝置開機時，開機載入器會將系統啟動至有效分割區。目前，對於使用者建構類型，裝置上一律會提供套件管理系統所知的全部軟體。

執行 OTA 時，系統更新程式會在非作用中的分割區 A 或 B 上寫入完整的新系統映像檔。此外，這項作業也會確保所有已知 Blob 都下載至 fxblob/blobfs 儲存空間，而 A 和 B 插槽都會共用這個儲存空間。成功完成後，系統會翻轉表示哪個是有效分割區的位元，並重新啟動至新的系統映像檔。也就是說，在任何時間點，都會有一個完整的系統映像檔佔用空間，但完全不會使用，而且在一段時間內，fxblob/blobfs 必須保留目前執行裝置軟體版本和新版本的 Blob。這樣就能更有效率地使用裝置資源。RFC-212 定義並大致說明瞭 Fuchsia 套件管理系統擴充功能的命名和概念，可減少系統映像檔的占用空間。做法是允許從系統映像檔排除套件，並在系統更新後下載至 fxblob/blobfs 儲存空間。這樣一來，舊版和新版套件就不會同時佔用 fxblob/blobfs 空間，

支援錨定封裝的另一個動機，是希望盡量減少不必要的網路流量。如果 Fuchsia 系統的大部分使用者完全不會使用特定軟體元件，則將這些元件排除在 OTA 之外，並僅在需要時下載，可能大幅減少要傳輸的資料量，進而降低伺服器和網路的容量需求。

定義

以下是根據 RFC-212 定義的適用術語和定義：Base、Bootfs 套件、快取、Eager update、垃圾收集、套件、套件集、套件版本、父項套件、永久套件、產品、產品建構、產品發布、子套件、系統更新、Universe、版本管理機構。

利害關係人

協助人員：

jamesr@google.com

審查者：

• etryzelaar@google.com (SWD)
• amituttam@google.com (PM)
• awolter@google.com (軟體組裝)
• markdittmer@google.com (安全性)
• gtsai@google.com (基礎架構)

社交：

軟體交付團隊內部進行了一系列設計討論，並討論了這項 RFC。我們與軟體交付、建構和組裝團隊的利害關係人，以及潛在客戶，共同審查了本 RFC 的早期版本。

需求條件

• 錨定套件的傳送機制不得需要額外服務或基礎架構，也就是說，將系統更新 (OTA) 傳送至目標裝置的機制，也適用於錨定套件。
• 您必須手動指定哪些套件屬於哪些錨定套件集。根據這項 RFC，我們不會實作任何機制，嘗試自動判斷哪些套件可能屬於哪些套件集。
• 實作範圍受限於 RFC-212 定義的限制，如下圖所示。具體而言，自動或隨選錨定套件「不會」涵蓋或支援下列情境：
  • 支援版本控管的委派作業。
  • 支援產品開箱即用體驗 (OOBE) 工作流程所需的套件。
  • 也就是說，如果 OOBE 必備的套件標示為自動或隨選錨定套件，套件管理堆疊就無法保證在需要時，所有 OOBE 工作流程所需的套件都能正常運作。這是因為在許多情況下，OOBE 工作流程包含設定網路。因此，系統無法保證在 OOBE 完成前，自動和隨選錨定套件可解析。

設計

錨定套件集

套件集是一組套件，所有套件都使用相同的策略交付及更新。生產裝置中最常使用的套件集是永久 (基礎和 bootfs) 集，這些套件集的主要特徵是永遠可用，且由產品定義設定：

• 描述套件的 Merkle 雜湊，確保套件完整性。
• 以及套件本身

在重新啟動至更新後的產品版本「之前」，系統會先下載這些檔案，做為 OTA 更新程序的一部分。因此，如果搭配 Fuchsia 的預設 ABR 分割配置 (A 和 B 分割區都包含可完整啟動的系統)，基本套件組的套件可能會在 fxblob/blobfs 中儲存兩次：如果套件不同，則 A 分割區產品中的一個版本會儲存在商店中，B 分割區產品中的一個版本也會儲存在商店中。在執行中的系統中，基本集中套件清單會反映在基本套件的 data/static_packages 檔案中。在套件解析過程中，這些套件會由基本解析器 (pkg-cache 的一部分) 解析。也就是說，這些要求會在本地解決，不需要網路連線。

自動和隨選 錨定套件組合與啟動檔案系統和基本組合有一些共同特徵，但本質上有所不同：

• 與基本套件相同，描述錨定套件的 Merkle 雜湊會在重新啟動至新系統版本前，下載至目標系統分割區。
• 與基本和啟動檔案系統套件不同，在重新啟動至新系統之前，Blob 本身不會下載至 fxblob/blobfs。

這樣一來，由於系統可避免在非揮發性儲存空間中保留多個版本的套件，因此可針對儲存空間大小最佳化 OTA 更新的下載階段。詳情請參閱下方的「Boot sequence with automatic anchored packages」(使用自動錨定套件的開機順序)。

自動和隨選 錨定套件的差異在於觸發套件解析器擷取套件的原因：

• 只要有任何具備在執行中 Fuchsia 系統上查詢解析器權限的適用元件要求解析套件，系統就會擷取隨選錨定套件。
• 在執行 OTA 後重新啟動至新的 Fuchsia 系統時，系統會盡快解析自動錨定套件。

錨定套件的垃圾收集

這項 RFC 建議，在日後可能修訂垃圾收集演算法之前，應適用下列錨定套件收集規則：

• 自動錨定套件下載至 fxblob/blobfs 後，在下次重新啟動至較新系統前，都會受到垃圾收集機制保護。
• 只有在系統版本 (因此 Merkle 雜湊) 變更，且不再屬於當時執行的系統版本時，自動錨定的套件才會進行垃圾收集。
• 隨選錨定套件不會受到垃圾收集機制額外保護，且會遵循 RFC-217 中有關開放套件追蹤的規則。

解決隨選錨定套件的問題

套件解析器已具備下載套件的功能，並可視需要將套件提供給執行中的系統。因此，使用這項功能取得隨選錨定套件非常簡單：只要系統上沒有的套件解析度一經解析，套件解析器就會下載 Blob，並透過 fxblob/blobfs 驗證及提供這些 Blob。

一律可用的套件組合與自動/隨選 錨定套件的主要差異在於，後兩者需要網路連線才能解析。

從執行系統的角度來看，隨選錨定套件不必明確標示為這類套件。要求套件時，解析器只會注意到套件快取中沒有 Blob，並啟動下載程序。

不過，開發人員可以決定是否將套件納入產品做為隨選錨定套件，且必須在產品定義中標記該套件：

• Fuchsia 產品定義會接受 on_demand_anchored 套件清單。
• ffx assembly product 工具會將清單發布至圖片組裝設定。

產品組裝期間：

• 套件 (二進位大型物件和資訊清單) 會納入主要產品套裝組合。
• 這些 Blob 不會納入用於刷寫裝置的 fxblob/blobfs。
• 隨選錨定集中的套件清單，建構方式與基本套件類似。這份清單會是 AssemblyManifest 的一部分，並納入更新套件。執行中的 Fuchsia 系統會在基礎套件的 data/anchored_packages 檔案中，找到這個套件組合的套件清單。

解決自動錨定套件的問題

與隨選錨定套件相同，開發人員可決定是否將套件納入產品做為自動錨定套件，且必須在產品定義中標記：

• Fuchsia 產品定義會接受 automatic_anchored 套件清單。
• ffx assembly product 工具會將清單發布至圖片組裝設定。

產品組裝期間：

• 套件 (二進位大型物件和資訊清單) 會納入主要產品套裝組合。
• 這些 blob 不會納入用於刷寫裝置的 fxblob/blobfs。
• 自動錨定集中的套件清單建構方式與基本套件類似。這份清單會是 AssemblyManifest 的一部分，並納入更新套件。執行中的 Fuchsia 系統會在系統更新套件的 data/anchored_packages 檔案中，找到這組套件的清單。

重新啟動至新版或升級版 Fuchsia 系統後，系統會解析這組套件。如前所述，這與 data/static_packages 中的套件明顯不同，因為這些套件一律存在，且 pkg-cache 知道這些套件。

使用自動錨定套件的啟動序列

系統的開機順序 (已設定自動更新套件) 如下：

• 在全新裝置首次啟動或 OTA 後重新啟動時，確認網路連線後：
  • 系統會執行 fxblob/blobfs 垃圾收集作業，清除舊版系統中存在的懸空 Blob。
  • 如果沒有網路連線，垃圾收集作業會延後，直到網路恢復連線為止。
• 開機程序會照常完成，且基本套件的所有套件都已可用。
• 啟動序列完成時，套件解析器會檢查自動錨定集中的每個 Blob 是否存在，並開始下載 fxblob/blobfs 中不存在的所有 Blob。
• 如果發生下載錯誤，解析器會繼續檢查自動錨定集是否有遺失的 Blob，並在系統累積正常運作時間時，重試下載遺失的 Blob。

套件可能無法使用

與僅提供永久套裝組合的系統不同，一旦隨選或自動錨定套裝組合開始運作，就無法保證所有套裝組合隨時都能使用。

根據預設，啟動程序不會因下載失敗或下載速度緩慢而遭到封鎖，除非產品明確要求這種行為並正確實作。主要有兩個原因：

• 裝置可能尚未設定網路連線，必須先完成開箱即用 (OOBE) 工作流程，才能下載隨選或自動錨定套件。
• 使用者體驗可能不佳。舉例來說，裝置在下載一組自動 錨定套件時，可能會失去網際網路連線，但使用者想使用裝置的簡單功能，而這些功能可透過基本套件組取得。

請注意，由於套件可能至少會間歇性無法使用，因此依附於這些套件的元件必須能夠妥善處理這種情況。具體來說，由於大多數用途的網路延遲和速度不明，因此無法保證透過網路擷取元件的呼叫會在特定時間內完成。詳情請參閱「回報套件供應情形」一節。

回報套裝組合的供應情形

與裝置上隨時提供所有已知套件的情況相比，OTA 後下載和 OTA 儲存空間節省的優點，是以可預測性為代價。這可能會衍生出相關規定，例如：

• 元件可能想知道依附元件是否已準備就緒，或是否仍在下載中，再呼叫特定函式。
• 特別是使用者互動式應用程式，可能需要實作機制，監控呼叫某些功能供應商時是否出現異常的等待時間，並向使用者顯示訊息，以管理他們的期望。
• 追蹤或偵錯工具可能需要檢查套件可用性的詳細資料或指標，例如套件是否存在、是否正在下載、下載速度、延遲、重試次數等。

撰寫這份 RFC 時，我們尚未全面瞭解具體詳細的規定，以及這些規定對 Fuchsia 平台變更的影響。因此，這類監控和可用性報表的詳細設計不在討論範圍內。我們可能會在日後的 RFC 或實作中解決這個問題。

根據目前的規劃，工具 (例如 debug_agent 或 zxdb) 可能是第一批採用某種形式的可用性報表和監控功能的元件。這樣一來，我們就能更瞭解需求、差距和日後需要解決的必要變更。複雜的應用實例 (例如與互動式 UI 互動、向使用者回報進度等) 不屬於這組初始應用實例的範圍。

實作

實作作業將分為多個階段，以便參與團隊之間同步處理，並在為 Fuchsia 產品啟用這項功能前驗證功能。

第一階段將在套件解析器和套件快取中實作純功能，這需要：

• SWD
  • 支援在啟動時從基礎套件的 data/anchored_packages 取得自動錨定套件清單，並提供自動錨定套件的 Blob。
• 建構、組裝
  • 支援在產品建構期間處理所需自動和隨選錨定套件清單，並為圖片提供 data/anchored_packages。
  • 更新大小檢查工具，支援錨定套件並正確反映建構和圖片大小。
• 安全性
  • 對自動和隨選錨定套件的解析度進行技術審查，包括面向網際網路的程式碼路徑。

第二階段將涵蓋準備工作，為 Fuchsia 產品啟用新功能。請按照下列步驟操作：

• SWD
  • 準備現有產品設定的變體，將部分套件從基本組合移至自動或隨選錨定組合。
• 伺服器端封裝基礎架構
  • 套件儲存空間，並與 Blob 儲存空間整合。

第三階段則會將自動或隨選錨定套件導入以 Fuchsia 為基礎的產品，並推出第一個應用程式。這項決定超出 RFC 的範圍。不過，從概念上來說，這需要：

• 選取的應用程式 / 維護團隊和測試團隊
  • 請檢查並調整應用程式，確保應用程式能夠處理暫時無法使用的依附元件。
  • 建立及調整測試和測試計畫，模擬並執行可能出現的一系列錯誤狀態 (下載速度緩慢、DNS 問題、連線中斷、開箱體驗等)。
• 版本管理
  • 請確保已完成端對端產品測試，保證 OTA 和 OOBE 工作流程不會依賴隨選套件。
  • 引導發布程序，將錨定套件納入所有階段，並最終向 Fuchsia 產品使用者推出。

data/anchored_packages 檔案

實作的核心元素是系統如何識別自動和隨選錨定套件。如前所述，這些檔案會列在 data/anchored_packages 中，與 data/static_packages 檔案類似。不過，與 static_packages 檔案的簡單鍵/值格式不同，這項格式會在開頭傳達更多資訊，供自動和隨選錨定套件使用：

• 是自動還是隨選。
• 以網址識別的套件。
• 套件雜湊。

因此，data/anchored_packages 檔案會是包含這項資訊的 JSON 檔案，概念上如下所示：

{
  "on_demand": {
    "fuchsia-pkg://fuchsia.com/package1": {
      "hash": "d5eb4bb8a394176f20a266bac7cd8a077579f57119c5e1ed0981cd5ea563c183"
    },
    "fuchsia-pkg://fuchsia.com/package2": {
      "hash": "d33da6cb5fc8787ae1386e85ff08a32c6e846668d5eb4bb8a394176f20a2681c"
    }
  },
  "automatic": {
    "fuchsia-pkg://fuchsia.com/package3": {
      "hash": "d189658d88636999abe2c4375409ace94fd0408d338e96692b8b8bad07c484d4"
    },
    "fuchsia-pkg://fuchsia.com/package4": {
      "hash": "e6c22775bac3301f18d012493ffc6c7fe442b59cd5eb4bb8a394176f20a266ba"
    }
  }
}

效能

這項 RFC 對效能的影響可分為以下幾個方面：

1. 在執行階段，以 Fuchsia 為基礎的產品效能，適用於 fxblob/blobfs 提供的套件。我們預期這個領域的執行階段效能不會有明顯變化，因為就錨定集已解決的套件而言，無論是套件快取提供的套件，還是執行的套件，都與基本套件沒有差異。

2. 在執行階段，以 Fuchsia 為基礎的產品會針對套件管理系統已知但尚未下載的套件，就 CPU 和記憶體耗用量而言，封裝組合解析度 (下載、驗證) 對 Fuchsia 產品整體效能的影響預計不大。不過，如果產品使用者想執行的功能需要下載套件，可能會受到影響。在這種情況下，使用者體驗會受到一定程度的影響，具體程度取決於下載速度。這類問題主要取決於使用者網際網路連線的速度和延遲時間，因此不在本 RFC 的討論範圍內。請注意，視套件下載進度而定，裝置上的應用程式可以向使用者說明情況，例如傳達「必要下載作業仍在進行中」的訊息。從使用者體驗的角度來看，這比裝置顯示沒有回應或處於不明狀態更理想。

3. 如果產品使用自動錨定套件，OTA 程序總時間會有所不同。我們預期「系統更新套件下載作業已開始」和「新版本正在執行」之間的平均時間會縮短，而「系統更新套件下載作業已開始」和「所有套件都已解決」之間的平均時間會增加。如先前項目所述，解決 fxblob/blobfs 上尚無的套件時，建議軟體依附於非永久套件，以便管理使用者的期望。對於某些類型的裝置，這項時間長度的變更可能不會造成太大問題，例如在無人使用時 (半夜) 例行更新的裝置。

4. 與以單一無線更新 (OTA) 形式發布更新的產品相比，為採用自動或隨選錨定套件的產品提供服務時，套件服務基礎架構最有可能會遇到不同的負載模式。這取決於多項因素，例如裝置在收到更新套件後重新啟動的時間 (適用於自動錨定套件)，或是使用者首次要求使用特定功能的時間 (適用於隨選錨定套件)。但其他因素 (例如地理位置，以及使用者是否採用特定功能) 也會導致套件服務基礎架構的負載，與僅提供靜態套件的產品不同。我們會在「未來工作」一節中討論這方面的內容。

5. 基於上述原因，建議您針對下列項目設定指標：(i) 更新套件的下載和安裝時間，以及 (ii) 首次重新啟動至新版本後，自動錨定套件的解決時間。這樣一來，就能更瞭解系統更新成功後，使用者體驗受到網路連線不穩或下載速度緩慢影響的頻率。

基準

使用錨定套件的產品可能會出現使用者可見活動的差異。因此，我們建議定期收集這類產品的額外基準，確保使用者體驗不會退步，並在基準顯示下列情況時採取因應措施：

• 在特定網路條件 (上傳 / 下載速度、延遲、封包遺失等) 下，解決特定產品的自動和隨選錨定套件組問題所需的時間。
• 在各種網路條件下，錨定套件解析失敗的頻率。
• 使用者透過 Fuchsia 產品要求功能時，該功能依附的套件尚未解決的頻率。

這些指標旨在提供資料，協助您合理判斷特定套件是否可移出基本集，或是否應將錨定套件移回基本集。

人體工學

工程工作流程

工程工作流程大致與目前使用工程建構版本可完成的工作相同，套件會從存放區伺服器動態提供，並提供 TUF 存放區。一般來說，元件不應處理依附元件的可用性等低階詳細資料，而套件解析程序會將這些詳細資料抽象化。

如果發現缺口，我們預計會擴充現有的 ffx 工具，支援錨定套件的測試和開發工作流程。

回溯相容性

這項工作會與現有的軟體交付堆疊用法回溯相容。套件網址命名空間結構或解析概念不會變更。

這項工作不會淘汰現有功能。因此，除非使用錨定套件，否則變更完全透明。

安全性考量

這項提案有安全性考量。這項提案與 RFC-145 有些許重疊，但從根本上來說，這項提案較為良性。

• 如同 RFC-145，我們會在系統執行階段解析套件，也就是套件解析器必須有權連上網際網路，至少要等到所有套件都解析完畢，且 Blob 儲存在 fxblob/blobfs 中為止。
• 與 RFC-145 不同，這項提案不會委派可執行套件集的授權。啟動新的 OTA 時，系統會知道整個套件宇宙的所有雜湊值。因此，產品定義和有效包裝的構成要件，與僅使用基本包裝的產品相同。

隱私權注意事項

我們認為提案不含任何會影響隱私權的新功能。不過，請注意下列事項：

建議您在「基準」一節中，先介紹新指標。這些指標的目的是造成使用者體驗迴歸。如果從生產裝置收集這類基準，則須經過隱私權審查。

測試

軟體交付堆疊的新擴充功能將由現有測試套件的擴充功能涵蓋，並涵蓋所有新程式碼路徑的單元測試、整合測試和端對端測試。

測試也會涵蓋錨定套件的解析度取決於先前垃圾收集作業是否成功，以及面臨磁碟空間即將用盡的情境。

如要評估採用錨定套件的 Fuchsia 產品使用者體驗，請驗證重要使用者工作流程，尤其是在網路狀況不佳時。

說明文件

接受這項 RFC 後，我們會：

• 更新「套件」的詞彙條目。
• 更新「概念」中的套件部分。
• 更新「IDK 中的套件」頁面。
• 在「入門指南」中更新產品套件頁面。
• 新增使用錨定套件時的更新設定資訊。

缺點、替代方案和未知事項

替代方案：為 Fuchsia 產品使用其他分割區配置

這個替代方案的語意範圍與先前著重於軟體傳送機制的方案不同，且與本 RFC 大致正交。但本文著重於自動和隨選錨定套件的重要原因之一：節省 Fuchsia 產品非揮發性儲存裝置的空間。

一般會假設這些產品是根據 ABR 分割配置建構而成：

• A 和 B 是可容納整個系統映像檔的分區
• R 做為緊急情況的復原磁碟分割區，適用於 A 和 B 都無法使用的情況

雖然這項概念已在許多不同類型的裝置中獲得驗證，但絕非唯一選擇。至少還有兩種可能性，可節省近半空間：

• AR 方案：只有一個系統磁碟分割區 (A)。OTA 是透過啟動復原映像檔 (R) 執行，然後系統分區 (A) 會遭到覆寫。
• AB 方案：A 和 B 都含有可用於重新刷寫其他系統分割區的復原軟體，不必另外建立復原分割區。

雖然這些替代分割區配置可達成在資源受限的裝置上提供更多可用磁碟空間的目標，但與著重於套件本身的做法大相逕庭，就節省空間的角度而言，甚至可視為正交。不過，錨定套件也能達成其他目標，例如減少網路流量，因此變更分割區配置是應獨立評估的選項，與這項提案無關。

之後的作業

移除 data/static_packages 檔案

我們可能會選擇淘汰並移除 data/static_packages 檔案，並將該檔案中列出的套件納入用途更廣泛且可擴充的 data/anchored_packages 檔案。

Notification API

這份 RFC 刻意不納入通知 API，但我們可能會在日後實作某種形式的通知 API，讓元件查詢套件解析狀態、下載速度或預估下載完成時間等資訊。

在系統更新套件中納入套件內容 Blob

視日後需求而定，我們可能會選擇在更新套件中加入套件的 meta.far 檔案，以及套件內容 Blob。舉例來說，這項資訊可用於估算自動和隨選錨定套件的下載時間。

針對特定工作流程進行最佳化

使用套件組合時，可針對特定工作流程進行最佳化。不過，這些最佳化措施可能會產生額外費用，或實作起來很複雜，尤其是考慮所有極端情況時。因此，這些考量因素不在本 RFC 的討論範圍內。但為了提供背景資訊，以下列出一些可能的最佳化做法：

• 積極運用隨選套件，可使用比定義產品的合併套件組更小的 fxblob/blobfs 儲存空間。在這種情況下，隨選套件可能會經常遭到垃圾收集，並重新下載需要使用的套件。雖然可行，但必須仔細設計這類產品的可能工作流程，確保隨時都有足夠的儲存空間，可存放所有使用的套件。
• 您可以在用於刷機的初始 fxblob/blobfs 映像檔中，加入自動或 (大部分)隨選錨定套件，因此在初始開箱體驗後，就不需要下載這些套件。雖然可以，但這會在初始映像檔和後續 OTA 之間產生細微差異，可能導致組裝和測試作業複雜化。

其他開發人員工具

納入自動或隨選錨定套件後，我們就能提供更多工具，協助開發人員。要建構哪些工具不在本 RFC 的範圍內，但一些潛在工具包括：

• 回報並美化列印套件依附元件圖表，醒目顯示直接和轉換依附元件，以利套件不一定可用。
• 透過 ffx repository serve 將套件提供給開發目標時，模擬非完美網路狀況，例如網路速度緩慢或連線問題間歇發生。

重新審查套件服務基礎架構

根據從採用自動和隨選錨定套件的產品收集到的網路指標，經營套件服務基礎架構的團隊可以取得洞察資訊，進而最佳化服務基礎架構，縮短使用者的下載時間或延遲時間。預期方面包括：

• 在各雲端區域中分配套件構件的儲存空間 bucket。
• 負載平衡，盡量縮短用戶端的存取延遲時間，例如使用 IP 地理位置判斷最接近的套件伺服器。
• 在推出大型更新時，動態調整套件伺服器執行個體數量。
• 在次要和主要版本發布前，預期負載模式。

既有技術和參考資料

• fuchsia.dev 中的套件
• Eager 套件 updates RFC
• 子檔案包 RFC
• 早期啟動套件 RFC
• 套裝組合 RFC