| RFC-0212：套件集 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 提議變更 Fuchsia 上的套件組合定義和選單 |
| 問題 | |
| 更小鳥 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年月分) | 2022-11-17 |
| 審查日期 (年-月-日) | 2023-03-07 |
摘要
這個 RFC 針對「套件集」一詞提供了正式定義，並提出套件集的新版架構。這個架構會根據套件提供的可用性和版本管控，表示套件組合的適用性和符合要求：
- 現有的三個現有套件組合
- 先前未與套件集整合的舊版軟體推送工作
- 新的套件組合讓您更靈活地交付 Fuchsia 軟體，可依產品要求提供。
提振精神
套件 F 套件可用於提供平台軟體和產品軟體，還用於各種不同的測試和開發工作流程。
每項 Fuchsia 產品會採用部分結合產品專屬的套件和平台提供的套件；此產品組合的內容會因產品而異。產品使用的所有套件不必同時提交，或是使用相同的策略進行更新。舉例來說，某些套件可能會作為無線更新的一部分下載，而其他套件則要等使用者採取行動才能下載。
「套件集」是產品使用的套件組合，其中所有套件都會以相同策略提供及更新。Fuchsia 目前使用三種不同的套件組合：底數、快取和宇宙。
Fuchsia 上的目前套件集狀態不足，原因如下：
- 尚未明確定義「套件集」字詞。
- 現有的套件集尚未清楚定義，且由於名稱不同，因此難以明確定義其行為。在不同的情境中，會重複使用相同的字詞，但意義不同。舉例來說，裝置在套件快取中儲存的套件組合與「快取」套件集不同。
- 現有套件集尚未更新，無法反映近期的軟體傳送 RFC，例如eagerly package updates、子套件或 bootfs 套件。
- 現有的套件組合無法滿足多項產品開發人員需求。例如：
- 在磁碟空間有限的情況下，系統應可延後擷取非必要的套件。
- 產品軟體應該可以與平台分開更新 (這項做法在 RFC-0145 中設計，但未包含在套件集定義中)。
- 開發期間應該能夠快速穩定地更新套件。
這個 RFC 旨在達成以下目標：
- 清楚定義「套件集」一詞。
- 定義潛在套件組合定義所在的設計空間。
- 說明現有套件概念在這個設計空間中的適用位置，並修正我們根據該概念參照這些概念的名稱。
- 找出設計空間中應由日後 RFC 設計填入的缺口。
- 找出不再需要且應淘汰的現有概念。
相關人員
講師：
- Abarth
審查者：
- wittrock (SWD)
- 阿密特丹 (PM)
- aaronwood (軟體組件)
- Markdttmer (安全性)
- 已設定 (DX)
- marvinpaul (伺服器基礎架構)
諮詢時間：
- yaar, senj, etrylezaar, galbanum, richkadel
社會化：
我們與軟體推送團隊內部的一系列設計討論，探討瞭如何促成這項 RFC 的工作。這份 RFC 中較早版本的文字已交由軟體組裝、伺服器基礎架構、第一方產品及 PM 團隊的相關人員進行審查。
定義
-
套件是一組檔案，例如資訊清單、中繼資料、零或多個執行檔 (例如元件) 和資產。「package」一詞也用於表示這類集合的定義 (例如由其建構規則定義的 Timekeeper 套件)，以及根據該定義產生的個別成果 (例如，在 2022 年 11 月 14 日以 Merkle 根為
de07b9f06ae01181b0536b61c7f643496025598c3a2908dca5c72fce191be5d1建構的 Timekeeper 套件)。針對這個 RFC，我們只會使用先前的意義。 - 套件版本 - 特定套件的單一執行個體 (例如，在 2022 年 11 月 14 日以 Mirkle 根層級
de07b9f06ae01181b0536b61c7f643496025598c3a2908dca5c72fce191be5d1建構的 Timekeeper 套件)。Fusia 目前不需要編號 (或甚至排序) 套件版本的編號。某些 Eager 更新套件的 CUP 中繼資料可能含有備用檢查 (如 RFC-0145 所定義) 使用的已排序版本號碼。 - 產品會定義建構作業將產生的軟體設定。最重要的是，產品通常會定義提供的使用者體驗類型，例如使用者可能會觀察到的圖形殼層、無論是否提供多媒體支援等等。
- 產品版本：特定產品的組合系統版本。產品版本是根據產品定義規格產生的成果。例如「Workstation 8.20220622.2.1」。
- 產品發布 - 已推送至更新管道的產品版本。
- 套件組合 - 請參閱下文。
- 版本管理授權 - 決定 Fuchsia 裝置應使用哪個套件版本的伺服器或存放區。在實際工作環境系統中，Omaha 就像版本管理機構，在主機上開發 TUF 存放區時一樣具有版本管理授權。
- Base (原始稱為「單體」) - 在此 RFC 之前定義的套件。基本套件組合的內容一律會顯示在已安裝產品發布修正版本的裝置上。這個 RFC 提議保留基本套件集。
- 快取 (原稱為「預先安裝」) - 在這個 RFC 之前定義的套件。幾乎所有情況下，裝置上都會顯示快取套件集的內容，但在某些情況下可能會更新在本機開發期間。這個套件組合並未在正式環境中使用。這個 RFC 建議建立新的以開發人員為主的流程，以取代快取套件集。
- Universe (原先稱為「可用」) - 在這個 RFC 之前定義的套件。系統會使用由版本管理授權機構決定的版本，以隨選方式下載宇宙套件組合的內容。這個套件組合目前並未用於實際工作環境。「universe」一詞用於指這個套件組合的內容，以及所有套件組合的內容。為避免這項 RFC 建議將宇宙套件重新命名為「可偵測」
- Eager 更新 - 在獨立產品版本的更新套件中，如 RFC-0145 所定義。
- Bootfs 套件 - 儲存在啟動檔案系統檔案系統中的套件 (如 RFC-0167 所定義)。
- 子套件：由 RFC-0154 中定義的其他套件所參照，且以不可分割的形式擷取的套件。
- 父項套件：參照 RFC-0154 中定義的子套件的套件。
- 垃圾收集 - 將不再需要的套件內容從 blobf 中移除的程序。
- 系統更新 (也稱為「OTA」) - 將 Fuchsia 裝置從一個產品版本更新至另一個產品的程序。
設計
套裝行程
套件組合是一組套件，其中的所有套件都會以相同的策略提交及更新。舉例來說，在基本套件集中，系統在更新時以產品版本決定的版本擷取所有套件。此基本套件組合中的套件保證會在裝置執行時出現在裝置上。
套件組合的內容是由產品定義。特定套件可能位於產品 A 的一個套件中，但在產品 B 中使用不同的套件組合 (或完全省略)。放置套件的套件會反映套件與產品之間關係；在產品運作方面重要的套件應置於套件組合中，藉此確保這些套件一律會顯示在裝置上。一般而言，套件只會存在於指定產品的單一套件中，但在某些情況下，套件可出現在多個套件集中。
有幾個相關但細微的「套件集」定義已根據使用字詞的上下文而發展。我們在下方說明其中一部分，以及可明確指稱定義的名稱。
- 符合資格的套件組合：裝置可以解析的一組套件。舉例來說，「符合資格的基本套件集」是指所有套件，都能成功解析及放置已提交的基本套件組合。
- 已建立的套件集 (也稱為建構依附元件集) - 建構 Fuchsia 產品時產生的一組套件。建構的套件集通常等於對應的合格套件組合，但在某些情況下，套件可能會更小。舉例來說，某裝置可能有數千個符合資格的宇宙套件，但版本可能無法產生上述任一套件。
- 已提交的套件集 - 已提交至裝置的一組套件。提交的套件集是對應合格套件集的子集。
本文的其餘部分著重於軟體推送系統的設計，因此也會討論「符合資格的套件集」定義。
建議的設計空間
軟體推送系統會回答兩大問題：
- 什麼項目會影響套件版本？
- 何時可在裝置上購買套件？
這個 RFC 提議根據這兩個問題來分類套件集，如下圖所示：
請注意，這兩種情況都沒有一個「最佳」答案；每個軸都代表兩個所需屬性之間的交換。在某些情況下，軸線的其中一端可能最適合，而其他用途則更適合。
軸 1 - 版本控制
判斷套件的目前版本是否正確，對於系統的安全性和可更新性至關重要。若要發布新功能及修正錯誤，您必須變更套件的版本；然而，如果具有選擇套件版本的實體遭到入侵，便可能用來部署不當或惡意的軟體版本。經常變更套件版本時，通常會執行較不成熟的軟體，或是未經測試的軟體組合。
版本管控軸是高靈活性和高確定性之間的交換。例如：
- 系統的重要元素不需要經常變更，而且必須集中控管，並受到嚴格控管。在這種情況下，建議將套件版本鎖定為平台或產品版本。
- 使用者應用程式可能會根據開發應用程式的組織速度而頻繁變更。在這種情況下，建議發布者不必等待產品發布，就能在相容裝置上推出新版本。
- 每當程式碼變更，開發人員進行偵錯的元件可能會每隔幾秒變更一次。在這種情況下，建議您立即更新該版本。
軸 2 - 可用性
套件是為了在 Fuchsia 裝置上啟用部分實用功能，且只有在裝置具有 (且已知正確) 的情況下才能執行。
可用性軸是在高可用性與低資源使用率之間交換。例如：
- 即使網路無法使用，系統的重要元素也必須隨時可供使用。在這些情況下，您需要將套件整個可能會使用期間都儲存下來。這表示更新時，系統會同時儲存舊版和目前版本的套件。
- 產品體驗中較不重要的部分可能不需要可用性保證。在這種情況下，最好先刪除舊版本的套件，再擷取更新版本，以降低儲存空間高峰需求。
- 部分使用者應用程式可能只供少數裝置使用。在這些情況下，建議只在有使用者打算使用的信號時擷取套件來消耗資源。
對應至現有概念
現有的套件集和與套件相關的 RFC 可分為四種不同的版本管控類別：
- 產品已修正套件版本：適用於基本和啟動檔案系統。
- 產品將特定套件的版本控制委派給具有限制的版本管理權：適用於快速更新的套件。隨著快速更新套件，產品發布可能會限制接受的最低版本。
- 產品將特定套件的版本控制委派給沒有限制的版本管理授權：適用於快取套件。
- 產品將網域中所有網址的版本控制委派給沒有限制的版本管理權：適用於不在基礎或快取集中的宇宙套件。請注意，只有產品發布不會定義組合中每個套件的存在。
現有的套件集和與套件相關的 RFC 可分為四種不同的可用性類別：
- 一律可用：適用於基本和啟動檔案系統。
- 幾乎一律可用：適用於快速更新的套件 (指定備用版本時) 和快取套件。在這些情況下，意圖是始終保持套件可用，但目前的快取套件解析度和垃圾收集演算法設計則意味著在某些情況下無法使用套件。
- 在系統更新後自動擷取：在未指定備用版本時適用於快速更新的套件。在提交系統更新後，只要網路的健康狀態良好，即可使用這些套件。
- 隨選擷取：適用於不屬於其他套件集的宇宙套件，例如基礎套件。在提出套件解決要求後一段時間，只要網路的健康狀態良好，即可使用這些套件。
子套件參照包含目標的內容雜湊，因此子套件會遵循父項套件的版本管控類別。子套件會以不可分割的形式透過父項解析 (若沒有解析父項的背景資訊就無法解析)，因此子套件會遵循父項套件的可用性。
總結來說，現有的套件概念適用於提議的設計空間，如下圖所示：
提議的變更
如上所示，將現有的套件概念對應至這個設計空間時，會立即發現數個問題：
- 現有概念並未涵蓋大部分設計空間，這表示目前的套件集無法針對許多潛在的有價值用途提供解決方案。
- 快取套件和快速更新的套件扮演著非常相似的角色。
- 因為快取套件解析度和垃圾收集演算法發生問題，所以不需要「幾乎隨時可用」套件。
- 現有概念的名稱並不遵循一致的模式，而且在大部分的情況下，都並未暗示該概念包含的設計空間部分。
- 數個概念 (例如熱量更新) 並未定義為套件集。
這個 RFC 提出的一系列變更結合在一起，可以解決這些問題，並實現更全面且一致的設計空間涵蓋範圍，如下所示：
下列各節將詳細說明上述各項變更。請注意，我們會按照預定的開始順序介紹這些 API，不過許多變更可以同時進行。文字內容會討論不同關係因關係而異的位置。
變更 1 - 為套件組導入統一命名法
在此 RFC 之前，套件集是以單一字詞命名。這是可行的，因為只有三組組合，且這些組合位於同一軸上，但就算是語言代碼名稱，也可能造成混淆。
這個 RFC 建議參照內含描述屬性屬性的簡短套件。每個詞組都包含一個用來說明集合中套件可用性的字詞，以及用來說明組合中套件版本管理版本的第二個字詞，如下表所定義：
| 適用期限 | 說明 |
| 永久 | 在任何情況下都能使用 |
| 自動 | 系統會在磁碟空間和網路可用性允許時，自動擷取這些套件 |
| OnDemand | 只有在裝置上的部分實體嘗試使用這些套件時，系統才會擷取這些套件 |
| 版本管理條款 | 說明 |
| 錨定標記 | 這些套件的版本是由產品發布所設定。 |
| 可升級 | 這個產品發布版本會選擇設下限制 (例如最低可接受的版本)，將控制權委派給這些套件的版本管理授權。 |
| 可供偵測 | 產品發布版本不會定義這個組合中的個別套件，而是將控制權委派給網址網域的版本管理授權。 |
舉例來說，如果頻繁更新不含備用內容的套件，該套件就完全稱為「自動可用性、可升級版本管理」套件組合的成員。在背景資訊和意義明確的情況下，這可能是縮寫為「自動和可升級」。
左下方區隔則會有兩個不同的套件組合，具有相同的版本管理和可用性行為：基準和啟動檔案系統。我們會保留這些名稱以參照這些套件組合，同時使用「永久可用性與錨定版本管理」來指稱這些套件共用的一般行為。
我們會保留現有的「快取」名稱，以參照快取套件集，直到取代這個集合為止 (請參閱變更 6)。
「宇宙」一詞的定義在 Fuchsia 上有所衝突。原始定義是所有建構套件的集合，且與字詞的定理意義一致。現在，更常見的「宇宙」是指建構但未包含在其他套件集中的套件，也就是說，基礎套件並不在宇宙中。這個定義與字詞的既定理含不一致。為了避免造成混淆，我們在設計空間的右上方時會使用「可偵測」的名稱，而非「宇宙」。
變更 2 - 淘汰「快取」套件集
快取套件組合和快速更新 (含備用方案) 是兩種不同的解決方案，可滿足相同需求：讓版本控制伺服器提供較新的套件版本，同時確保裝置離線時，仍可持續使用某些版本的套件。
快速更新 RFC-0145 中定義的套件，為這個問題提供更完善的解決方案：
- 與快取套件不同，伺服器通訊問題不會導致緊急更新的套件無法解決
- 與快取套件不同，如果裝置離線，經常更新的套件不會還原為較舊版本
快取套件目前只能在開發人員流程中使用，但由於上述問題，快取套件並不適合這些用途。由於快速更新套件的優勢，在實際工作環境流程中使用快取套件絕對不合適。
我們將淘汰快取套件概念，這表示 SWD 不會進一步改善流程。在部署合適的替代方案並獲選加入之前，我們不會移除資料流或開發人員說明文件 (請參閱變更 6)。
請注意，淘汰快取套件不代表淘汰名稱相似的「套件快取」元件。
變更 3：移除 RFC-0154 中的子套件組合限制
根據 RFC-0154，子套件必須將其置於其父項設為「相同的套件中」。隨著我們推出新的套件類別，會導致產品維護人員每次變更一組遞移子套件時，都必須更新套件集定義，因此這項要求會變得難以滿足。
由於 RFC-0154 已經放寬了相同的套件集限制，但此 RFC 已正式移除這項作業。如上所述，子套件仍遵守父項的可用性和版本控制 (因此仍可做為父項套件組合的成員)，但產品維護人員不再需要獨立納入子套件做為參照這些套件組合的頂層成員。
安全性稽核工具可用於驗證產品的每個版本是否包含預期的套件組合。用於這項驗證的黃金檔案將包含錨定版本套件集中的所有子套件，以遞移方式加入。這可確保將子套件或巢狀子套件新增至錨定版本套件組合之前，都會經過人工審查。
變更 4 - 重新設計垃圾收集演算法
Fuchsia 目前的套件垃圾收集 (GC) 演算法是早期設計階段，並未隨著軟體推送的發展而擴大。即使現在發生必要的套件刪除作業，以及保留不必要的套件，我們仍會遇到故障模式。目前的 GC 演算法無法處理引入新的套件集。
我們將發布替代 GC 實作的要求和演算法，以便在未來的 RFC 中容納更多套件集。
變更 5 - 設計自動和錨定套件組合
在產品的每個發布期間，產品維護人員都必須同時測試多個不同平台和產品套件的固定版本，以確保能正確整合。目前，如果產品要包含固定版本的套件，唯一的方法就是將該版本納入基本套件組合中。也就是說，在系統更新期間，這些套件可能需要兩個副本一起儲存在磁碟中，這樣就很難在儲存空間有限的裝置上執行 Fuchsia。
如要解決這個問題，請實作自動可用性 (錨定版本套件組合)，例如支援在成功提交系統更新前，無法下載版本的產品套件。我們將於近期發布這個套件的設計，並設為後續追蹤 RFC。
變更 6 - 設計以開發人員為主的替代套件交付流程
如上方變更 2 中所述，快取套件流程不適合開發人員在開發期間輕鬆、快速且穩定地更新套件。我們將著重在開發人員的需求，研究更理想的解決方案，然後依 RFC 格式發布設計。
我們預期這個以開發人員為主的新流程會疊加在工程建構的設計空間上，但我們會在 RFC 中進一步說明相關資訊。
變化 7 - 依照需求設計錨定和/或隨選升級套件組合
這些套件集可讓產品維護人員定義具有固定版本或受限版本的套件，這類版本會在需要時才會擷取。
這些套件組合可能有助日後的產品使用，但與變更 5 中設定的自動和錨定套件不同，我們尚未有推出客戶。
發生特定產品或開發人員需求時，我們會設計及實作這兩種套件組合，或兩者都實作。
總結
完成這些變更 (包括建議的後續 RFC) 後，軟體推送堆疊會為產品開發人員提供更多彈性。例如：
- 產品可以將非必要的套件從基礎套件移至自動和錨定套件，或隨選與錨定套件集，以降低資源使用率，同時又能降低版本管理的控管權。
- 產品將能夠包含可使用可升級套件集單獨升級的套件。
- 產品將控制這些可升級套件的供應情形。包括將這些項目放在永久且可升級的套件集中，以便隨時使用。
- 這些可升級套件可以參照建構產品時，還不知道的其他套件。
- 方法是使用子套件 (由父項套件設定參照的套件版本)，或使用可探索套件組合中的網址 (由版本管理授權機構設定參照的套件版本)。
- 這些受參照的套件的可用性會遵循參照套件 (如果參照子套件的情況)，或是由參照套件控管 (如果參照的是可探索套件)。
- 只要啟用可探索的套件組合，即可使用產品發布中未明確定義的套件。
- 在所有情況下，套件只能從產品信任的存放區擷取。
- 軟體推送會管理可用的 blob 儲存空間，確保在需要執行系統更新時移除非重要套件，以及確保系統會在可用空間時自動擷取自動套件。
- 開發人員可在開發期間輕鬆更新需要修改的套件。
此 RFC 中描述的變更也會對 SWD 堆疊內的假設產生重大影響。例如：
- 您必須在套件快取中儲存多個版本的套件。可升級套件可能包含產品已包含在其錨定組合中的子套件參照。產品和可升級的套件不知道彼此的版本管理架構，因此無法協調確保兩者的版本相同。同樣地，相同可升級套件集中的不同套件可能包含對相同套件但不同版本的子套件參照。
- 套件快取中的套件必須能夠支援多個套件集。如上所述，可升級的套件可能包含產品已納入套件的子套件參照。有時候，兩個套件組合中都會是同一個套件。決定何時移除套件時，您必須考量套件支援的所有套件集。
- 進行套件擷取和垃圾收集作業需要協調。可升級和自動的套件集，都會在系統更新程序外擷取新的套件版本。只有在可用 blob 儲存空間充足時，這些作業才能成功。在某些情況下，可能需要延後或取消這些作業，因為空間無法使用。在其他情況下，可能需要撤銷其他套件，才能讓作業成功。
- 套件解析器與套件集之間的關係將會改變。如今，基礎和宇宙套件解析器與名稱相同的套件集之間存在鬆散相關性，但這樣的關聯並不精確，且如果使用一個解析器來解析傳送至其他套件集的套件，則無法一氣呵成。這種關聯性無法擴充至具有較複雜關係的大量套件集，我們也不會為此 RFC 討論中的新套件集新增其他套件解析器。日後選取及命名套件解析器將成為軟體推送堆疊的實作詳細資料，讓我們將與確認套件版本相關的工作與確保其可用性相關的工作分離。
- 可能需要改變執行力強制執行機制。目前只有基本套件的內容能在實際工作環境版本中執行，這表示控制可執行性的簡單機制就已足夠。日後每個套件組合 (以及其參照的子套件) 中的套件內容可能需要執行。這可能需要使用更複雜的強制執行機制。
實作
這個 RFC 的初始實作主要會在說明文件異動部分，詳情請見下文。最常使用的套件集 (即基礎、啟動檔案系統和快取) 名稱不會受此 RFC 變更。每當有機會出現時，我們會在原始碼和工具中更新指向「宇宙」的參照。如果已淘汰的原始碼和工具使用「宇宙」一詞，我們通常不會更新這些參照。
提議的變更 4、5 和 6 需要遵循 RFC，且這些 RFC 會記錄導入的變更實作。
效能
長期來看，這個 RFC 會縮減基本套件集的大小，現有的部分套件會移至資源需求較低的新版套件集。長期下來，這將改善多項效能指標，尤其是磁碟和網路使用率。
如果產品選擇將套件從永久供應情形的套件移至有自動或隨選可用性的套件，則解決套件的延遲時間可能會增加。
安全性考量
我們相信此 RFC 帶來的淨安全性影響為正數：
- 此 RFC 正式定義可升級的套件集。可升級的套件集可讓產品更輕鬆地更新某些套件來修補安全漏洞
- 這個 RFC 可讓套件之間建立更明確的關係，讓您更容易對軟體推送行為瞭解原因。這可能使安全性長期增加，不過改善難以量化。
- 如要放寬在提議的變更 3 中使用子套件的限制，必須透過安全團隊進行分析。
隱私權注意事項
此 RFC 帶來的淨隱私權影響持平：
- 這個 RFC 可讓您更輕鬆地定義僅在使用者操作後才下載的套件，以便建立網路流量與使用者行為的關聯
- 這個 RFC 可讓產品更輕鬆地更新產品軟體版本，也更容易修補隱私權安全漏洞
- 受此 RFC 影響的軟體推送元件不會直接處理使用者資料
測試
提議的變更 4、5 和 6 需要遵循 RFC，而這些 RFC 會記錄所導入變更的測試內容。
說明文件
接受此 RFC 後，我們就會：
- 為「套件集」、「基本套件」以及各個版本管控和可用性類別新增詞彙表項目。
- 更新套件的詞彙表項目
- 更新概念套件的章節
- 更新 IDK 中套件的頁面
- 更新入門指南的產品套件頁面
缺點、替代項目和未知
缺點 1 - 名稱變更
針對宇宙套件和積極更新的套件，RFC 導入了命名法的變化。任何命名變更都會造成開發人員的混淆，但許多開發人員並未使用這些字詞，在先前版本中並未全程使用。我們認為名稱變更的混淆程度，會比長期使用具邏輯性且自我一致的名稱。
替代方法 1 - 允許保證和/或自動可探索的套件
上方提議的變更部分會將設計空間的右下方標示標示為「不適用」。我們並不支援這種組合，原因是其有邏輯關係：如要保證或自動載入套件，必須在產品版本符合條件時，符合納入可升級套件組合的條件。