| RFC-0212：套件集 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 建議對 Fuchsia 上的套件集定義和選單進行一系列變更 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2022-11-17 |
| 審查日期 (年-月-日) | 2023-03-07 |
摘要
這項 RFC 提供「套件集」一詞的正式定義，並提議更新套件集架構。這個架構會根據套件組合提供的可用性和版本控管功能，以及以下項目，表示套件組合：
- 現有的三種套裝組合
- 先前未與套件集整合的軟體交付工作
- 新套件組合：可根據產品要求，更彈性地提供 Fuchsia 軟體。
提振精神
套件是 Fuchsia 的軟體發布單位。套件可用於交付平台軟體和產品軟體，也適用於各種不同的測試和開發工作流程。
每項 Fuchsia 產品都會使用產品專屬套件和平台提供的套件，但兩者的比例因產品而異。產品使用的所有套件不一定要同時交付，也不一定要使用相同的策略更新。舉例來說，部分套件可能會在無線更新時下載，其他套件則可能要等到使用者採取某些動作才會下載。
「套件組合」是指產品使用的一組套件，組合中的所有套件都會採用相同的策略交付及更新。Fuchsia 目前使用三種不同的套件組合：基礎、快取和宇宙。
由於下列幾項原因，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 團隊的利害關係人審查。
定義
-
<
檔案包是一組檔案，例如資訊清單、中繼資料、零或多個可執行檔 (例如元件) 和資產。「套件」一詞同時用於指稱這類集合的定義 (例如由 建構規則定義的 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 之前定義的套件集。系統會根據版本管理機構決定的版本，視需要下載宇宙套件組合的內容。這個套件組合目前未用於正式版。「宇宙」一詞同時用於指稱這個套件組合的內容，以及所有套件組合的內容。為避免混淆，本 RFC 建議將 universe 套件集重新命名為「discoverable」。
- 搶先更新：獨立於產品發布版本更新套件的機制，如 RFC-0145 所定義。
- Bootfs 套件 - 儲存在啟動檔案系統檔案系統中的套件，如 RFC-0167 所定義。
- 子套件 - 根據 RFC-0154 的定義，子套件是指由其他套件參照並以原子方式擷取的套件。
- 父項套件 - 參照子套件的套件，如 RFC-0154 所定義。
- 垃圾收集：從 blobfs 移除不再需要的套件內容。
- 系統更新 (又稱「OTA」) - 將 Fuchsia 裝置從一個產品版本更新至另一個版本的程序。
設計
套裝
套件集是一組套件，其中所有套件都使用相同的策略交付及更新。舉例來說，在基本套件集中，系統更新時會擷取所有套件，版本則由產品發布決定。只要裝置正在執行，這組基本套件中的套件就一定會存在於裝置上。
套件組的內容由產品定義。特定套件可能存在於產品 A 的一個套件集中，但存在於產品 B 的不同套件集中 (或完全省略)。套件所屬的套件集會反映套件與使用該套件的產品之間的關係；對產品運作至關重要的套件應放在套件集中，確保這些套件一律會出現在裝置上。一般來說，特定產品只會存在於一個套件集中，但有時套件可能會出現在多個套件集中。
「套件集」一詞的定義會因使用情境而異，但彼此之間有細微的關聯。下文將介紹其中幾項，並提供可明確指稱定義的名稱。
- 符合資格的套件組合 - 裝置可解析的一組套件。舉例來說，「符合資格的基本套件組合」是指裝置可成功解析並放入所提供基本套件組合的所有套件。
- 建構的套件集 (也稱為建構依附元件集)：建構 Fuchsia 產品時產生的一組套件。建構的套件組合通常等於相應的合格套件組合，但在某些情況下，建構的套件組合可能會大幅縮小。舉例來說，裝置可能擁有數千個符合資格的 Universe 套件，但建構作業可能不會產生任何套件。
- 已傳送的套件組 - 已傳送至裝置的套件組。已送達的套件組合是相應符合資格套件組合的子集。
本文的其餘部分著重於軟體發布系統的設計，因此會說明「符合資格的套件組合」定義。
建議設計空間
軟體交付系統會回答兩個重要問題：
- 套件版本取決於哪些因素？
- 裝置何時會收到套件？
這項 RFC 建議採用二維設計空間，根據以下兩個問題將套件集分類，如下所示：
請注意，這兩種情況都沒有「最佳」答案；每個軸都代表兩種理想屬性之間的取捨。在某些情況下，軸的一端可能最適合，而在其他情況下，軸的另一端則較為合適。
軸 1 - 版本管控
判斷套件的目前正確版本，對系統的安全性和可更新性至關重要。變更套件版本是發布新功能和修正錯誤的必要步驟，但如果具有選擇套件版本權限的實體遭到入侵，可能會用來部署不當或惡意版本的軟體。頻繁變更套件版本通常會導致軟體不夠成熟，或軟體組合未經過共同測試。
版本控制軸是在高靈活度和高確定性之間取捨。例如：
- 系統的重要元素不需要經常變更，且必須集中嚴格控管。在這些情況下，建議將套件版本鎖定至平台或產品版本。
- 使用者應用程式可能會根據開發機構的步調頻繁變更。在這些情況下，發布商應為相容裝置發布新版本，不必等待產品發布。
- 開發人員偵錯的元件可能會在每次程式碼變更時，每隔幾秒就變更一次。在這些情況下，最好立即自動更新版本。
Axis 2 - Availability
套件可啟用 Fuchsia 裝置上的部分實用功能，但前提是套件必須存在於裝置上 (且已知正確無誤)。
可用性軸是在高可用性和低資源用量之間取捨。例如：
- 即使網路無法連線，系統的重要元素也必須隨時可用。在這種情況下，必須儲存整個可能使用套件的時間。這表示更新期間會同時儲存套件的先前版本和目前版本。
- 產品體驗中較不重要的部分可能不需要可用性保證。在這種情況下，建議先刪除舊版套件，再擷取更新版本，以減少尖峰儲存空間需求。
- 部分使用者應用程式可能只適用於一小部分的裝置。在這些情況下，最好只在有信號指出使用者打算使用資源時，才擷取套件並耗用資源。
對應至現有概念
現有的套件組合和套件相關 RFC 分為四種不同的版本控制類別：
- 產品會修正套件版本：適用於基本和啟動檔案系統。
- 產品將特定套件的版本控管作業委派給具有限制的版本控管機構：適用於急切更新的套件。如果套件更新頻率很高，產品發布時可能會限制可接受的最低版本。
- 產品將特定套件的版本控管權委派給版本管理機構，不受任何限制：適用於快取套件。
- 產品將網域中所有網址的版本控管權委派給版本控管機構，不受限制：適用於不在基本或快取集中的宇宙套件。請注意，這是唯一一個類別，產品發布時不會定義套件組中每個套件的存在狀態。
現有的套件集和套件相關 RFC 分為四種不同的可用性類別：
- 一律可用：適用於基本和啟動檔案系統。
- 幾乎一律可用：適用於急切更新的套件 (指定備援版本時) 和快取套件。在這些情況下，意圖是讓套件一律可用，但目前快取套件解析和垃圾收集演算法的設計，表示在某些情況下，套件將無法使用。
- 系統更新後自動擷取：適用於未指定備援版本時，急切更新的套件。系統更新完成後，只要網路連線正常，這些套件就會在一段時間後提供下載。
- 隨選擷取：適用於不屬於其他套件組合 (例如基礎套件) 的宇宙套件。只要網路正常運作，這些套件會在提出套件解析要求後一段時間提供。
子封裝參照包含目標的內容雜湊，因此子封裝會遵循上層套件的版本控管類別。子套件會與父項套件以原子方式解析 (且無法在沒有解析父項套件的環境下解析)，因此子套件會遵循父項套件的可用性。
總而言之，現有的套件概念符合建議的設計空間，如下圖所示：
建議的變更
如上所示，將現有套件概念對應至這個設計空間時，會立即發現幾個問題：
- 現有概念並未涵蓋設計空間的大部分內容，這表示目前的套件組合無法為許多潛在的寶貴用途提供解決方案。
- 快取套件和搶先更新套件扮演的角色非常相似。
- 我們不希望出現「幾乎一律可用」的套件，這類套件只會因為快取套件解析和垃圾收集演算法的問題而存在。
- 現有概念的名稱不遵循一致的模式，且在大多數情況下，不會暗示概念所占用的設計空間部分。
- 許多概念 (例如搶先更新) 並未定義為套件組合。
這項 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 - 允許保證和/或自動探索的套件
上方的「建議變更」部分會將設計空間的右下部分標示為「不適用」。我們不支援這種組合的原因是，我們認為這不合邏輯：如要保證或自動載入套件，必須由產品版本明確指定，此時套件會符合可升級套件組的納入條件。