RFC-0271：錨定套件

問題陳述

目前，Fuchsia 中的系統更新 (OTA) 實作功能需要同時儲存兩組完整的 blob。這麼做很簡單，但對於磁碟空間不足的裝置而言，這會造成問題。

摘要

本 RFC 提出了錨定套件的實作方式，最初是在 RFC-212 中說明。這些套件組合符合下列不變量：

• 系統更新 (OTA) 期間只會下載永久錨定的套件 (啟動檔案系統，根據 RFC-212 的基礎)。
• 系統會透過 Merkle 雜湊值來識別套件及其 blob。對於自動錨定和隨選錨定套件，更新套件會納入包含此資訊的 meta.far 封存雜湊。
• 系統更新套用後，裝置已啟動至新系統版本，系統會在某個時間點下載自動錨定和隨選錨定套件。
• RFC-212

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

• 因此，如果未執行系統更新，就無法將其更新至新版本，因為所有套件的加密雜湊仍會隨系統更新發布。
• 從應用程式的角度來看，無論套件是透過 OTA 發行，還是以錨定套件的形式發行，都不會造成影響。不過，如果應用程式要存取尚未解析的套件提供的功能，可能會發生延遲。詳情請參閱「效能」一節。
• 自動錨定套件不會隨需求下載，這與工程建構中 TUF 存放區的套件和隨選錨定套件不同。而是在系統開始更新後才下載。

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

提振精神

在實際運作中的 Fuchsia 系統中，目前常用的系統更新機制會透過三個分割區的「ABR」配置執行完整更新。分割區 A 和 B 各包含一個完整的系統映像檔。R 分區包含最小復原分區，但不在本 RFC 的範圍內。

其中一個分割區 (A 或 B) 是任何時間點的有效分割區，也就是說，開啟裝置時，啟動載入程式會將系統啟動至有效分割區。目前，對於user 建構類型，套件管理工具所知的所有軟體，在裝置上都會隨時可用。

執行 OTA 時，系統更新器會將完整的新系統映像檔寫入非活動分區 A 或 B。此外，它還可確保所有已知 Blob 都會下載至由 A 和 B 插槽共用的 fxblob/blobfs 儲存空間。成功完成後，系統會翻轉指示哪個分割區為有效分割區的位元，然後重新啟動至新的系統映像檔。也就是說，在任何特定時間點，一個完整的系統映像檔會佔用空間，但完全不會使用，而且在 fxblob/blobfs 必須保留目前執行中的裝置軟體版本和新版本的 blob 的時間範圍內，這麼做可更有效率地使用裝置資源。RFC-212 已定義並概略說明 Fuchsia 套件管理系統擴充功能的名稱和概念，以減少系統映像檔的占用空間。方法是允許系統在更新後，將套件從系統映像檔中排除，並下載至 fxblob/blobfs 儲存空間。這樣一來，舊版和新版套件都會在 fxblob/blobfs 上占用空間，因此就不需要時間視窗。

另一個支援錨定套件的動機，是希望盡量減少不必要的網路流量。如果以 Fuchsia 為基礎的系統中，大多數使用者都不會使用特定軟體元件，將這些元件從 OTA 中排除，並只在需要時下載，可能會減少大量要傳輸的資料，進而減少伺服器和網路所需的容量。

定義

以下術語和定義的適用方式，請參考 RFC-212 的定義：Base、Bootfs 套件、快取、積極更新、垃圾收集、套件、套件組合、套件版本、父項套件、永久套件、產品、產品版本、產品發布、子套件、系統更新、Universe、版本化權威。

相關人員

協助人員：

jamesr@google.com

審查者：

• etryzelaar@google.com (SWD)
• amituttam@google.com (PM)
• awolter@google.com (Software Assembly)
• markdittmer@google.com (安全性)
• gtsai@google.com (基礎架構)

社會化：

這份 RFC 是在軟體交付團隊內部一系列設計討論中討論過。我們已與軟體提交、建構和組合團隊的利益相關者和潛在客戶，共同審查本 RFC 中的早期版本。

需求條件

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

設計

錨定套件組

套件組合是一組套件，所有套件都會使用相同的策略進行提交和更新。在實際裝置中，最常使用的套件組合是永久 (base 和 bootfs) 組合，這些組合具有以下主要特徵：一律可用，且由產品定義設定：

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

會在 OTA 更新程序的前面下載，以便重新啟動至更新後的產品版本。因此，結合 Fuchsia 的預設 ABR 分割方案 (其中 A 和 B 分割區都包含可完全啟動的系統)，基礎集合的套件可能會在 fxblob/blobfs 中儲存兩次：如果兩者不同，則商店中會出現來自 A 分割區的產品版本，以及來自 B 分割區的產品版本。在執行中的系統中，基礎套件的 data/static_packages 檔案會反映基礎套件中的套件清單。在套件解析過程中，這些套件會由 pkg-cache 的基礎解析器解析。換句話說，這些問題會在本機解析，不需要網路連線。

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

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

這樣一來，系統就能針對儲存空間大小最佳化 OTA 更新的下載階段，因為這樣可避免在非揮發性儲存空間中保留多個套件版本。如需瞭解這項功能，請參閱下方的「含有自動錨定套件的啟動序列」。

自動和隨選 錨定套件的差異在於觸發事件，會導致套件解析器擷取套件：

• 只要任何符合資格的元件具有在執行中的 Fuchsia 系統上查詢解析器的權限，並要求套件的解析結果，系統就會立即擷取隨選錨定套件。
• 在 OTA 執行後，系統會盡快重新啟動至新的 Fuchsia 系統，並解析自動錨定的套件。

錨定套件的垃圾收集

本 RFC 建議，在日後垃圾收集演算法可能修訂前，針對錨定套件的收集作業，應套用下列規則：

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

隨選錨定套件的解析度

套件解析器已具備下載套件，並可依需求在執行中的系統上提供套件的功能。因此，您可以輕鬆將這項功能用於按需錨定套件：只要系統無法取得套件的解析結果，套件解析器就會下載 blob，並透過 fxblob/blobfs 進行驗證及提供。

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

從執行系統的角度來看，隨選錨定套件不必明確標示為此類套件。當套件要求時，解析器只會注意到其 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 平台的具體詳細要求，以及這些要求對 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. 在 fxblob/blobfs 上可用的套件，在執行階段的以 Fuchsia 為基礎產品效能。我們不預期這個部分的執行階段效能會出現明顯變化，因為錨定集合的已解析套件與基礎套件相比，在套件快取提供方式或執行方式上並無差異。

2. 在執行階段，套件管理系統已知但尚未下載的套件，其在以 Fuchsia 為基礎的產品上的效能。在 CPU 和記憶體消耗方面，解決方案 (下載、驗證) 對以 Fuchsia 為基礎的產品的整體效能影響應屬於無害。不過，如果產品使用者想要執行的功能取決於仍在下載中的套件，則影響可能會明顯可見。在這種情況下，使用者體驗會受到一定程度的影響，具體取決於下載速度。這項程度取決於使用者網際網路連線的速度和延遲時間，因此超出本 RFC 的範圍。請注意，如果裝置端應用程式依賴仍在下載的套件，可能會向使用者說明情況，例如傳送訊息指出所需下載作業仍在進行中。從使用者體驗的角度來看，這比裝置沒有回應或處於不明狀態來得好。

3. 對於使用自動錨定套件的產品，OTA 程序的整體時間長度會有所變動。我們預期「下載系統更新套件」和「新版本正在執行」之間的平均時間會縮短，而「下載系統更新套件」和「所有套件都已解析」之間的平均時間會增加。如前述關於解決 fxblob/blobfs 尚未提供的套件時所提及，建議您讓依賴非永久性套件的軟體準備好管理使用者的期望。對於某些裝置類型來說，這項時間長度變更可能不太重要，例如在深夜無人使用的情況下，裝置會定期更新。

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

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

基準

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

• 在特定產品的自動和隨選錨定套件，在定義的各種網路條件 (上行 / 下行速度、延遲、封包遺失等) 下，解析所需的時間。
• 在各種已定義的網路狀況下，錨定套件無法順利解析的頻率。
• 使用者以 Fuchsia 為基礎的產品要求功能的頻率，這些功能取決於尚未解析的套件。

這些指標旨在提供資料，以便做出合理的決定，例如是否可將特定套件移出基本套件，或是是否應將錨定套件移回基本套件。

人體工學

Eng 工作流程

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

我們預計會擴充 ffx 周圍的現有工具，以便在發現差距時，支援錨定套件的測試和開發工作流程。

回溯相容性

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

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

安全性考量

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

• 與 RFC-145 相同，我們會在系統執行階段解析套件，也就是說，套件解析器需要連線至網際網路的權限，至少要等到所有套件都解析完畢，且 blob 都儲存在 fxblob/blobfs 中為止。
• 與 RFC-145 不同，此提案不會將可執行套件的權限委派給其他人。在啟動至新的 OTA 時，系統會知道整個套件宇宙的所有雜湊值。因此，產品定義和有效套件的組成方式，與只使用基本套件的產品相同。

隱私權注意事項

我們認為該提案並未納入任何會影響隱私權的新功能。不過，請考量下列事項：

建議您在「基準」一節中提早介紹新指標。這些指標的用意是造成使用者體驗迴歸。如果這些基準是從正式版裝置收集而來，則必須經過隱私權審查。

測試

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

測試也會涵蓋以下情況：錨定套件的解析取決於先前是否成功進行垃圾收集，且磁碟空間已接近滿載。

如要評估以 Fuchsia 為基礎的產品 (使用固定套件) 的使用者體驗，請務必驗證重要的使用者工作流程，尤其是在網路條件不佳的情況下。

說明文件

在接受這項 RFC 後，我們會：

• 更新「package」的詞彙表項目。
• 更新「概念」中的套件相關部分。
• 更新「IDK 中的套件」頁面。
• 更新「入門指南」中的產品套裝方案頁面。
• 新增資訊，說明如何在使用錨定套件時設定更新。

缺點、替代方案和未知因素

替代方案：為以 Fuchsia 為基礎的產品使用其他分割配置方案

這個替代方案不包含與先前軟體提交機制相關的語意範圍，且與此 RFC 大不相同。不過，這篇文章著重於自動和隨選錨定套件的其中一個重要原因：節省以 Fuchsia 為基礎的產品非揮發性儲存裝置空間。

這些產品通常會假設採用 ABR 分割方案：

• A 和 B 是可放入整個系統映像檔的分區
• 當 A 和 B 都無法使用時，將 R 做為緊急情況的復原分割區

雖然這項概念已證明可行，並用於多種不同類型的裝置，但絕非唯一的做法。至少還有兩種方法可以節省近一半的空間：

• AR-scheme：只有一個系統分割區 (A)。OTA 會透過啟動至復原映像檔 (R) 來執行，然後系統分區 (A) 會遭到覆寫。
• AB 配置：不使用單獨的分區進行復原，而是在 A 和 B 中包含復原軟體，可用於重新刷新其他系統分區。

雖然這些替代分割區方案可在受限裝置上提供更多可用磁碟空間，但與專注於套件本身的做法大不相同，從節省空間的角度來看，這兩者可視為互不相干。不過，錨定套件也可以滿足其他目標，例如減少網路流量，因此變更分割區方案是一種選項，應獨立於這項提案評估。

日後的作業

移除 data/static_packages 檔案

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

Notification API

我們會刻意將這項作業排除在本 RFC 的範圍之外，日後可能會選擇導入某種形式的通知 API，讓元件可以查詢套件解析狀態、下載速度或下載完成的預估時間。

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

視未來需求而定，我們可能會選擇在更新套件中加入套件的 meta.far 檔案，以及套件內容 Blob。例如，這可讓您預估自動和隨選錨定套件的下載時間。

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

套件組合可讓您針對特定工作流程進行最佳化。不過，這些最佳化做法可能會產生額外費用，或是實作方式相當複雜，尤其是在考量所有極端情況時。因此，這些考量事項超出本 RFC 的討論範圍。不過，為了提供背景資訊，以下列舉一些可能的最佳化方式：

• 積極運用隨選套件，可讓您使用 fxblob/blobfs 儲存空間，其大小比已定義產品的組合套件還要小。在這種情況下，隨選套件可能會經常遭到垃圾收集，並重新下載需要使用的套件。雖然這麼做是可行的，但您必須仔細設計此類產品的可能工作流程，確保在任何時間點，都能有足夠的儲存空間來容納所有使用中的套件。
• 您可以在用於刷新的初始 fxblob/blobfs 映像檔中，加入自動或 (大部分的) 隨選錨定套件，這樣一來，您就不需要在初始開箱體驗後下載這些套件。雖然可能會在初始映像檔和後續 OTA 之間引入細微差異，但組合和測試可能會變得複雜。

其他開發人員工具

由於包含自動或隨選錨定套件，因此開發人員可以使用其他工具。決定要建構哪些工具不在本 RFC 的範圍內，但以下是一些可能的工具：

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

重新檢視套件服務基礎架構

根據從採用自動和隨選錨定套件的產品收集到的網路指標，負責套件服務基礎架構的團隊可能會獲得有助於改善服務基礎架構的洞察資料，進而縮短下載時間或降低使用者延遲。預期的面向包括：

• 將套件構件儲存至各雲端區域的儲存值區。
• 負載平衡，以盡可能縮短用戶端的存取延遲時間，並使用 IP 地理位置等方法，判斷最接近的套件伺服器。
• 在推出大型更新時，動態調整套件伺服器的執行個體數量。
• 在次要和主要版本推出前，預先瞭解預期的負載模式。

既有技術與參考資料

• fuchsia.dev 中的套件
• Eager 套件 updates RFC
• 子檔案包 RFC
• Early boot packages RFC
• 套件組合 RFC