有關 CentOS-8 的問題

1. CentOS Stream 是甚麼？

請另外參閱 CentOS Stream 常見問題

簡短的答案：我們正在與 RHEL 的領導層合作，好讓 RHEL 的開發更透明並且由社群共同參與。

有很多「待定」的工作仍要進行才能達至上述目標，因為我們期望盡可能與 Red Hat 公開、共同地設計／開發這一切。RHEL 過往一直是內部開發的。現在這會公開進行，讓互動更出發生。我們稱它為 CentOS Stream。

1.1. 會有多個 stream 還是一個？

現時只有一個 stream。我們（CentOS 及 RH）或許會選擇在將來增加更多。（請留意將事情 *簡化* 了，其實有時技術性問題主導政策，有時剛剛相反）。

1.2. 我們怎樣能善用 Streams 保持程式庫在最新狀態？

我們必須明白 Stream 以下個 RHEL 發行版本為目標，因此你過往若不曾看見套件被頻密地改版，這大概會保持原狀。若果你有一個簡單的修正，或反向移植了新的功能，那麼我們期望透過 pull request 及討論，最終納入該改動。

我們也在考慮這如何應用在 fasttrack 及 SIG 架構等軟件庫，因為某些程序也許更適用。

一個簡單的比喻是「RHEL 8.1 發行後，CentOS Stream 將會用來開發 8.2 的內容」。

1.3. Stream 可以引入新的套件嗎？Stream 的貢獻模式與 EPEL 包裝者有向分別？

「官方」的 CentOS Stream 套件反映 RHEL 開發中的源碼。要是它不獲 RHEL 開發者接納，它便不會出現在「官方」的 Stream 發行中。

要是忽略「我們還未建設它」的機制，貢獻給 SIG 或 EPEL 大致相同。指引或政策上或許有異，但就只有這些分別。

1.4. 既然 EL 及 EPEL 必需合作，EPEL 扮演著甚麼角色？

EPEL 指導委員會及 CentOS 計劃必需共同尋求合作的方式。我們期望 EPEL 能同時配合 Stream 及標準發行版本。

對，我們將會有提交的標準，但我們還未定立它們。最低限度你可預期：

1. 程式碼必須獲上游接納。
2. 程式碼必須是纍積的（不停用或減少功能）
3. 程式碼必須含文檔，或解釋為何需要作改動。
4. 若適用，程式碼必須連同測試。

=== 正確的名稱是 CentOS Stream 還是 *8* Stream？ ==

現時只存在 CentOS Stream，但基於技術性原因我們在 yum／dnf 或許會以 stream 變數標籤為 8-stream。這不是官方的答案。

1.5. Stream 的內核在開發階段會與 RHEL／CentOS 的內核保持 kABI 兼容性嗎？

就下個 RHEL 次發行版本而然，是的。要是你發現偏差，這是一個錯誤，請告訢我們。

2. 我看不見 CentOS-8 的 updates 軟件庫

[updates] 軟件庫已全面消失，因為隨著套件獲建設／測試並推送到鏡像，所有更新都出現於 BaseOS 及／或 AppStream 內。

3. 每個架構都有一個 os 及 kickstart 目錄。它們的目錄佈局及內容似乎很相似。

kickstart 是 os 目錄於發行時的快照。這樣人們便可部署相同的內容而不是移動的目標，因為 BaseOS／AppStream 將會不斷加入更新。

4. CentOS 8 的 codeready-developer 軟件庫在哪裡？

PowerTool 軟件庫收錄了來自 codeready-developer 軟件庫的套件。CodeReady linux Builder 這個註冊商標不能被採用。

5. minimal iso 及 live media 在哪裡？

它們被討論中，主要視乎有多複雜。

6. 有方法將 CentOS-7 升級至 CentOS-8 嗎？leapp 呢？

在 RHEL 下，leapp 工具程式能進行就地升級，但它的用途極之有限。見 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/upgrading_to_rhel_8/troubleshooting_upgrading-to-rhel-8#known-issues-upgrading-to-rhel-8 。暫時未有計劃為 CentOS 提供 leapp。

Translation of revision 9