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