| RFC-0212：套件組 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 針對 Fuchsia 的套件集定義和選單提出一系列變更 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2022-11-17 |
| 審查日期 (年-月-日) | 2023-03-07 |
摘要
這份 RFC 提供「套件組合」一詞的正式定義，並提出套件組合的更新架構。此架構會根據套件組合提供的版本控制資訊，說明套件組合的可用性和相容性：
- 三個現有的套件組合
- 先前未與套件集整合的舊版軟體提交工作
- 新的套件組合，可根據產品要求，更彈性地提供 Fuchsia 軟體。
提振精神
套件 套件用於提供平台軟體和產品軟體，也用於各種不同的測試和開發工作流程。
每個 Fuchsia 產品都會使用一些產品專屬套件和平台提供的套件；這些套件的內容會因產品而異。並非所有產品使用的套件都需要同時發布，或採用相同的策略進行更新。舉例來說，部分套件可能會在無線更新的過程中下載，而其他套件則可能要等到使用者採取某些動作才會下載。
「套件組合」是產品使用的套件集合，其中所有套件都會使用相同的策略進行提交和更新。Fuchsia 目前使用三種不同的套件組合：base、cache 和 universe。
由於以下幾個原因，Fuchsia 上套件集的目前狀態不足：
- 「套件組合」一詞未明確定義。
- 現有的套件組未明確定義，且其提供的行為並未在名稱中明確標示。相同字詞在不同情境中重複使用，但含義不同。舉例來說，裝置在套件快取中儲存的套件組合，與「快取」套件組合不同。
- 現有的套件組合尚未更新，無法反映最近的軟體提交 RFC，例如急切套件更新、子套件或bootfs 套件。
- 現有的套件組合無法滿足多項產品開發人員的需求。例如：
- 在磁碟空間有限的情況下，應可延後擷取非必要的套件。
- 產品軟體應可獨立於平台更新 (這項功能是在 RFC-0145 中設計，但未納入套件組定義)。
- 開發期間應可快速且可靠地更新套件。
本 RFC 旨在達成以下目標：
- 明確定義「套件組合」一詞。
- 定義潛在的套件組合定義所屬的設計空間。
- 說明現有套件概念在這個設計空間中的位置，並根據這些概念精修我們用來參照這些概念的名稱。
- 找出設計空間中的空白，並在日後的 RFC 中填入設計內容。
- 找出不再需要且應淘汰的現有概念。
利害關係人
協助人員：
- abarth
審查者：
- wittrock (SWD)
- amituttam (PM)
- aaronwood (Software Assembly)
- markdittmer (安全性)
- sethladd (DX)
- marvinpaul (伺服器基礎架構)
諮詢：
- yaar, senj, etrylezaar, galbanum, richkadel
社會化：
這份 RFC 的相關工作是在軟體提交團隊內部一系列設計討論中討論而成。我們已與軟體組裝、伺服器基礎架構、第一方產品和 PM 團隊的利益相關者，共同審查本 RFC 中的早期版本。
定義
-
套件是一組檔案，例如資訊清單、中繼資料、零或多個可執行檔 (例如元件) 和資產。「package」一詞既可用來表示這類集合的定義 (例如 Timekeeper 套件，其定義由建構規則定義)，也能用來表示根據該定義產生的個別構件 (例如 Timekeeper 套件，其建構時間為 2022 年 11 月 14 日，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 套件組合重新命名為「discoverable」。
- 積極更新 - RFC-0145 定義的機制，可獨立於產品發布版本更新套件。
- Bootfs 套件：儲存在啟動檔案系統檔案系統中的套件，如 RFC-0167 所定義。
- 子套件：根據 RFC-0154 定義，由其他套件引用並以原子方式擷取的套件。
- 父項檔案包：參照 RFC-0154 中定義的子檔案包的檔案包。
- 垃圾收集：當不再需要套件內容時，從 blobfs 中移除套件內容的程序。
- 系統更新 (也稱為「OTA」) - 將 Fuchsia 裝置從一個產品版本更新至另一個版本的程序。
設計
套裝組合
套件組合是套件的集合，其中套件組合中的所有套件都會使用相同的策略進行提交和更新。舉例來說，在基本套件集合中，系統會在系統更新期間擷取所有套件，並根據產品發布版本決定套件版本。只要裝置正在執行，這個基本套件組合中的套件就保證會出現在裝置上。
套件組合內容由產品定義。特定套件可能會出現在產品 A 的一個套件組合中，但在產品 B 中則是出現在不同的套件組合中 (或完全省略)。套件放置的套件集反映套件與使用該套件的產品之間的關係；對產品運作至關重要的套件應放置在套件集中，以確保這些套件一律會在裝置上顯示。一般來說，套件只會出現在特定產品的一個套件組合中，但在某些情況下，套件可能會出現在多個套件組合中。
根據「套件組合」一詞的使用情境，我們已發展出幾個相關但略有不同的定義。我們會在下方介紹其中幾個，並提供可用於明確指涉定義的名稱。
- 符合資格的套件組合：裝置可解析的一組套件。舉例來說，「符合資格的基礎套件組合」是指裝置可成功解析並放入其已提交基礎套件組合的所有套件。
- 已建構的套件集 (也稱為建構依附元件集) - 建構 Fuchsia 產品時產生的一組套件。已建構的套件組合通常等同於相應的符合資格套件組合，但在某些情況下，可能會大幅縮小。舉例來說，裝置可能有數千個符合資格的 Universe 套件，但組建作業可能不會產生任何這些套件。
- 已送達的套件組合：已送至裝置的套件組合。提交的套件組合是對應的符合資格套件組合的子集。
本文件的其餘部分將著重於軟體提交系統的設計，因此「符合資格的套件組合」定義。
建議的設計空間
軟體提交系統可解答兩個重要問題：
- 套件版本的決定因素為何？
- 何時可以在裝置上使用套件？
本 RFC 提出了二維設計空間，可根據下列兩個問題分類套件組合：
請注意，在兩種情況下都沒有「最佳」答案，每個軸代表兩個理想屬性之間的權衡。在某些用途中，軸的一個端點可能最適合，而在其他用途中，光譜的另一端可能更適合。
軸 1 - 版本管控
判斷套件目前的正確版本，對系統的安全性和可更新性至關重要。如要發布新功能和修正錯誤，就必須變更套件版本，但如果有權選擇套件版本的實體遭到入侵，則可能會用於部署不當或惡意版本的軟體。經常變更套件版本通常會涉及執行較不成熟的軟體，或是未經過共同測試的軟體組合。
版本控制軸是高靈活性和高決定性之間的取捨。例如：
- 系統的關鍵元素不需要經常變更，且必須受到嚴格的集中控管。在這種情況下，建議將套件版本鎖定為平台或產品版本。
- 終端使用者應用程式可能會根據開發該應用程式的機構的節奏而經常變更。在這種情況下，發布者最好能直接在相容裝置上發布新版本，而無須等待產品發布。
- 開發人員偵錯的元件可能會在程式碼每次變更時，每隔幾秒就變更一次。在這種情況下，建議立即自動更新版本。
軸 2 - 供應情形
套件可在 Fuchsia 裝置上啟用一些實用功能，但只有在裝置上有這些套件 (且已知為正確的套件) 時，才能啟用這些功能。
可用性軸是高可用性和低資源利用率之間的取捨。例如：
- 系統的關鍵元素必須隨時可用，即使網路無法使用也一樣。在這種情況下，您必須在整個可能使用套件的期間儲存套件。這表示在更新期間，會同時儲存套件的舊版和新版。
- 產品體驗中較不重要的部分可能不需要提供可用性保證。在這種情況下，建議您在擷取更新版本前刪除舊版套件，以減少儲存空間需求的尖峰值。
- 部分使用者應用程式可能只會用於少數裝置。在這些情況下，建議您只在有使用者意圖信號時，才擷取套件來使用資源。
對應至現有概念
現有的套件組合和套件相關 RFC 可分為四個不同的版本控制類別：
- 套件版本由產品固定：適用於 base 和啟動檔案系統。
- 產品將特定套件的版本控制權委派給具有限制的版本管理權威：適用於急切更新的套件。對於急切更新的套件，產品發布版本可能會限制可接受的最低版本。
- 產品將特定套件的版本控制權委派給版本管理權威，且沒有任何限制：適用於快取套件。
- 產品將網域中所有網址的版本控制權委派給版本管理權威，且不設任何限制：適用於不在基礎或快取集合中的宇宙套件。請注意，這是產品版本未定義套件組合中所有套件存在與否的唯一類別。
現有的套件組合和套件相關 RFC 可分為四個可用性類別：
- 一律可用：適用於 base 和啟動檔案系統。
- 幾乎隨時可用：適用於急速更新的套件 (指定備用版本時) 和快取套件。在這些情況下，意圖是讓套件一律可用，但目前快取套件解析和垃圾收集演算法的設計，意味著在某些情況下，套件將無法使用。
- 系統更新後自動擷取：如果未指定備用版本，則適用於急切更新的套件。只要網路運作正常，這些套件就會在系統更新完成後一段時間後推出。
- 隨選擷取：適用於不在其他套件組合 (例如 base) 中的宇宙套件。在網路正常運作情況下，這些套件會在套件解析要求提出後一段時間後提供。
子套件參照包含目標的內容雜湊，因此子套件會遵循其父項套件的版本控制類別。子套件會與其父項一起以原子方式解析 (如果沒有解析父項的上下文，就無法解析)，因此子套件會遵循其父項套件的可用性。
總而言之，現有的套件概念符合建議的設計空間，如下所示：
建議的變更
將現有套件概念對應至上述設計空間時，會立即看到幾個問題：
- 現有的概念無法涵蓋設計空間的大部分，這表示目前的套件組合無法為許多潛在的實用用途提供解決方案。
- 快取套件和立即更新套件扮演的角色非常相似。
- 我們不希望有「幾乎隨時可用」的套件，這類套件只會出現在快取套件解析和垃圾收集演算法中出現問題時。
- 現有概念的名稱並未遵循一致的模式，且在大多數情況下，不會暗示該概念所占用的設計空間。
- 其中幾個概念 (例如急速更新) 並未定義為套件組合。
本 RFC 提出一系列變更，可一併解決這些問題，並提供更全面且一致的設計空間涵蓋範圍，如下所示：
下文將詳細說明每項變更。請注意，我們會按照要啟動的順序引入這些變更，但許多變更可以同時進行。在變更彼此相關的情況下，本文會討論這項關係。
變更 1：為套件組合引進統一名稱
在本 RFC 之前，套件組合名稱都是由單字組成。由於只有三組，且沿著單一軸線排列，因此這麼做是可行的，但即使如此，簡短的名稱還是會造成一些混淆。
這份 RFC 建議使用簡短的詞彙來參照套件組合，並說明這些套件提供的屬性。每個詞組都包含一個詞彙，說明套件組合中的套件可用性，以及另一個詞彙，說明套件組合中的套件版本，如下表所定義：
| 可用性期限 | 說明 |
| 永久 | 這些套裝方案適用於所有情況 |
| 自動 | 在磁碟空間和網路可用情況允許的情況下，系統會自動擷取這些套件 |
| OnDemand | 只有在裝置上的某個實體嘗試使用這些套件時，系統才會擷取這些套件 |
| 版本管理條款 | 說明 |
| 錨定 | 這些套件的版本是由產品版本設定。 |
| 可升級 | 產品發布作業會將控制權委派給這些套件的版本管理單位，並視需要加入限制，例如最小可接受的版本。 |
| 可供偵測 | 產品版本不會定義此組合中的個別套件，而是將控制權委派給網址網域的版本管理權威。 |
舉例來說，如果是沒有備用版本的急迫更新套件，會全數視為「自動可用性、可升級版本」套件集的成員。如果背景和含義明確，則可縮寫為「自動且可升級」。
在左下方區段中，我們有兩個不同的套件組合，具有相同的版本和可用性行為 - base 和啟動檔案系統。我們會保留這些名稱來參照這些套件組合，並使用「永久可用、錨定版本」來參照這些組合共用的一般行為。
我們會保留現有的「cache」名稱，用於參照快取套件組合，直到這個組合遭到取代為止 (請參閱變更 6)。
「universe」一詞在 Fuchsia 上的定義相互衝突。原始定義是所有已建構的套件集合，這與集合理論的含義一致。目前「宇宙」一詞通常是指已建構但未納入其他套件組合的套件，也就是說，基本套件並非宇宙的一部分。這個定義與該詞彙的集合理論含義不一致。為避免造成混淆，我們在指稱設計空間右上角區塊時，使用「可探索」而非「宇宙」這個名稱。
變更 2 - 淘汰「cache」套件組合
快取套件組合和備用版本的立即更新套件是兩種解決方案，可滿足相同的需求：讓版本控制伺服器提供較新版本的套件，同時確保部分套件版本可供使用，即使裝置離線也一樣。
RFC-0145 定義的積極更新套件為此問題提供了更可靠的解決方案：
- 與快取套件不同，伺服器通訊問題不會導致急迫更新的套件無法解析
- 與快取套件不同，如果裝置離線，急速更新的套件不會還原為舊版本
目前快取套件只用於開發人員流程，但 (由於上述和其他問題) 不適合這些用途。由於及時更新套件具有許多優點，因此在實際工作流程中使用快取套件絕非理想做法。
我們將淘汰快取套件概念，這表示 SWD 不會再投資流程的進一步改善。我們不會移除流程或開發人員文件，直到適當的替代方案已部署並採用為止 (請參閱變更 6)。
請注意，淘汰快取套件並不代表淘汰名稱相似的「package cache」元件。
變更 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 儲存空間時，這些作業才能成功。在某些情況下，由於空間不足，因此可能需要延後或取消這些作業；在其他情況下，可能需要將其他套件逐出，才能讓作業成功。
- 套件解析器和套件組合之間的關係將有所變更。目前，基本和 Universe 套件解析器與同名套件組之間的關聯性較為鬆散，但這種關聯性並不精確，在某些情況下，一個解析器會用來解析其他套件組的套件。這種關聯無法擴展至具有更複雜關係的大量套件組合，我們也不會為此 RFC 中討論的新套件組合新增額外的套件解析器。日後，套件解析器的選取和命名將成為軟體提交堆疊的實作細節，讓我們能將與套件版本相關的作業與與確保套件可用性相關的作業分開。
- 執行可能性的執行機制可能需要變更。目前只有基本套件的內容可在實際發布版本中執行，這表示控制可執行性的簡單機制就足夠了。日後，每個套件組合中的套件內容 (以及它們參照的子套件) 可能都需要可執行。這可能需要更複雜的執行機制。
實作
這個 RFC 的初始實作內容主要是說明文件變更，詳情請參閱下文。這個 RFC 不會變更最常用的套件組合名稱 (即 base、啟動檔案系統和 cache)。我們會在原始碼和工具中，視情況將「universe」的參照項目更新為「可探索」。如果已淘汰的程式碼和工具使用「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 - 允許保證和/或自動可探索的套件
上方的「建議變更」部分標示設計空間的右下方為「不適用」。我們不支援這種組合，因為我們認為這不符合邏輯：為了確保套件可自動載入，必須由產品版本明確指定，且該版本符合可納入可升級套件組的條件。