為C#開發者更新Linux軟體包

Linux套件管理與Windows的不同

[0:00 - 0:38] Tim從討論來自Windows的開發者經常遇到的一個常見障礙開始介紹。 在Windows上，每個應用程式通常會獨立管理其更新。 Visual Studio與Edge獨立檢查更新，而後者則與您的列印機驅動程式分開更新。 沒有單一系統追踪安裝在您機器上的所有內容。

Linux採用集中管理的方法。 類似apt（Advanced Package Tool）這樣的套件管理器會追踪從官方儲存庫安裝的每個軟體。 當您運行一次更新時，apt會一次性查詢儲存庫中的每個已安裝套件。 瀏覽器更新、庫補丁、SDK升級和安全修復都通過同一管道到達。

對C#開發者而言，這有實際的影響。 您的.NET運行時、您的HTTPS調用依賴的OpenSSL庫以及您的應用程式連結的系統級依賴項都由該系統管理。 如果您是首次在非Windows平台上使用C#，掌握如何使用套件管理器可以為您省去日後追查神秘構建失敗的麻煩。 只需一條apt upgrade就能將整個堆疊保持一致，而在Windows上這需要在許多獨立的更新程式之間進行協調。

圖形使用者介面：Update Manager

[0:38 - 1:34] 對於喜歡可視化工作流的開發者，Tim首先介紹了Update Manager。Linux Mint 包含一個類似於Windows Update的工具。 右下角工具列的小圖標可以打開它，您將會看到將要更新的內容：Microsoft Edge，Firefox，curl，libssh等等。 每個項目顯示當前版本、新版本和下載大小。

所有套件預設為選中，雖然您可以取消勾選項目以跳過某個特定更新。 如果專案需要某個工具的特定版本，不希望在開發衝刺中更改，這將很有用。

您點擊"安裝更新"，在提示時輸入密碼，然後等待過程完成。 密碼提示出現是因為修改系統套件是行政操作，我們會在下一節中介紹。

圖形使用者介面做得好的一件事是：根據風險等級分類更新，並對可能影響系統穩定性的變更更為保守。 對於剛接觸Linux的開發者，只想保持其環境健康而不想操心細節，Update Manager是個不錯的預設選擇。

理解sudo

[1:34 - 1:51] 在進入終端之前，Tim花點時間解釋sudo，因為它出現在每次命令行套件操作中。 值得到先理解它的作用再開始輸入。 大多數Windows使用者帳戶預設是管理員帳戶，允許您全面存取以安裝、移除和修改系統軟體。 Linux採取相反的方法：您的帳戶以有限權限運行，僅在需要時提升為管理員權限。

在命令前加上sudo會觸發密碼提示以驗證您的身份。 身份驗證後，該命令會以root權限執行，然後權限會恢復到正常水平。 套件管理（安裝、移除或更新軟體）是系統級操作，可能影響機器上的每個應用程式，因此顯式的sudo前綴可以確保您不會在原本僅打算做其他事情時爭相修改系統包。

如果您使用過Windows，可以將其視為與以管理員身份運行Visual Studio類似，只是不同於Linux，您只提升每條具體命令而不是整個應用程式。 它是一個更有針對性的模型。

命令行：apt update

[1:51 - 2:28] 與sudo涵蓋後，Tim轉向終端。 在那裡工作讓您有機會更細緻地控制更新過程，他按順序講解了三條命令。 理解每一條命令的作用很重要，因為如他所指出，名稱具有誤導性。

第一個命令是：

sudo apt update

sudo apt update

一個常見的假設是這個命令可以更新套件。 其實不然。 apt update更新套件索引，這是一個可用軟體的本地目錄。 隨著時間推移，目錄會隨著維護員發布新的版本而過時，因此運行該命令會從儲存庫伺服器下載最新版本。 您的機器上沒有軟體更改。這純粹是資訊獲取步驟。

運行後，apt報告有多少個套件有新版本可以使用。 您可以在承諾變更之前檢查完整列表：

apt list --upgradeable

apt list --upgradeable

這可以對每一個有新版本可用的套件進行逐行查看，包括當前和新版本號。 如果您在機器上使用.NET，這是您可能會看到SDK更新、運行時補丁的地方，或者您應用程式依賴的庫的變化。 了解哪些.NET版本投入使用在您的機器上有助於您判定某些更新是否安全應用，或者是否需要先進行測試。

命令行：apt upgrade

[3:01 - 3:40] 一旦索引更新，Tim進入第二個命令 — 實際安裝更新版本的一個：

sudo apt upgrade

sudo apt upgrade

注意命名：upgrade是實際變更套件的命令。 這種分雙步行事的設計是有意為之。 它將"檢查可用的內容"階段與"應用變更"階段分開，給予您時間來審閱、研究或備份，而不必在進行發送場地上的動作之前移動任何內容。

在程式底層，upgrade遵循嚴格的規則，對於可以做和不可以做的事情都有具體規範。 它會下載和安裝您系統上已存在套件的新版本，但絕不會移除現有套件或安裝之前未安裝的新套件。 當需要一個不安裝的依賴以便安裝新版本時，upgrade會把該套件攔住，而不是自動拉用新的依賴。

這樣的好處是可預測性。 保持您的.NET堆疊最新很重要，但以受控的方式進行同樣重要。 系統首先會用一個將要變更的內容摘要來提醒您並請求您確認後才進行，因此沒有經過您明示同意的東西不會發生任何變化。

命令行：apt full-upgrade

[3:40 - 4:19] 在安全更新完成後，Tim介紹了第三個命令，用來處理所有被upgrade故意留下的內容：

sudo apt full-upgrade

sudo apt full-upgrade

upgrade故意避開的情況。 如果某個套件更新需要安裝新依賴或移除衝突的套件，full-upgrade會處理此類情況。 內核升級、主要系統庫變更和操作系統級別補丁在這裡應用。

以分步的方式進行這個步驟能給您一個分層的處理方式。 如果在複雜的依賴解析過程中出現了問題，您已經應用完直接更新的內容，只需排除更複雜的問題。

對於管理Linux上進行C#應用編譯的構建管道的團隊而言，這種分階段工作流程尤其有意義。 在自動CI/CD環境中，您可能會選擇僅運行full-upgrade保留給計畫的維護窗口，以便在更深層次的系統變化後確認一切構建和通過。

為什麼套件數量不同

[2:28 - 3:01] 令人大惑不解的是：Update Manager可能會顯示23個更新，而命令行報告79個套件。 這些並不是不同的更新項； 這是同一系統以不同的計數方式。

圖形使用者介面將相關的套件分組為邏輯單位。 Update Manager中的單一"Firefox更新"實際上可能由Firefox二進位檔、其語言包、它依賴的共享庫和配置包組成，每個都由apt單獨跟踪。 因此Update Manager所呈現的一個更新，apt列為四到五個個別的套件升級。

了解這一點，錯位不再令人困惑。 有人可能會說"我有100個套件要升級"對於同一組由Update Manager顯示為30個更新的更改來說。

Flatpak：一個獨立的套件管理器

[5:56 - 6:41] 易於遺漏的一點是：Linux可以安裝多個套件管理器，而apt只知道它管理的套件。 Flatpak是一個這樣的替代選項；它是基於sandbox的系統，將應用程式與其依賴項一起打包，將其與系統的其餘部分隔離。

如果您通過Flatpak 安裝了軟體，運行apt upgrade將不會影響那些應用。 您需要分開更新它們：

flatpak list
flatpak update

flatpak list
flatpak update

flatpak update將使這些套件達到最新版本。 保持定期檢查是個好習慣，特別是如果您通過它安裝了IDEs、資料庫工具或通信應用程式。

在Linux上，軟體可以通過apt、Flatpak、Snap，甚至手動安裝到達。 每個提供自己更新的機制，因此全面的更新例行應考慮到所有這些。 如果你習慣了每個應用程式都攜帶自己的更新，那麼這裡的關鍵區別就是你需要知道哪個包管理器擁有哪塊軟體，並針對每一個運行正確的更新命令。

您應該使用哪種方式？

[4:19 - 5:32] Tim的看法是兩種方法都是有效的，正確的選擇取決於您的工作流程。 如果您更習慣使用可視介面，Update Manager會通過點擊操作來處理與apt相同的更新。 您不需要記住命令或擔心執行順序錯誤。 話雖如此，值得花心思適應命令行：自動化。 您可以建立簡單的shell腳本並安排每周定期以cron方式執行所有更新序列。 一段三行的腳本，讓您不用操心即可保持系統更新，是一種重要的投入，隨著時間的推移不斷積累價值。

除了自動化以外，命令行還使您能根據環境具有選擇性地應用某些升級級別，或將輸出引入其他工具進行分析。 這些選項在圖形介面中是不可用的。

審核您的安裝套件

[7:16 - 7:54] 更新過程還有一個有用的副產品：查看更新列表的雙重作為審計安裝系統的作用。 當您看到更新隊列中的某個套件時，值得問一問您是否還需要它。

當您主要使用Edge時可能會在更新列表中看到Firefox，反之亦然。 為跨瀏覽器測試web應用程式而保持兩個瀏覽器的安裝是有意義的，但是更廣泛的原理是更新列表揭示了您開發環境的全部範圍。 來自先前項目的過時工具、被當時拉進作為依賴從不清理的開發庫、您六個月前已經忘記安裝的套件：它們都會出現在這裡。

這種型別的維護工作遠比您期望的更有用。 一個乾淨的開發環境更容易在團隊成員之間複製，更容易容器化，也不太可能產生"在我這裡運行"的Bug。 如果您的Linux機上安裝有Dockerfile中没有的包，您可能依賴不會在生產中存在的東西。 熟悉部署C#應用程式到Docker使這個連接變得更具體清晰，連結您當地安裝的包和生產環境。

結論

[7:54 - 8:25] 正如Tim演示的，整個過程—無論是通過Update Manager還是命令行—最多需數分鐘，並保護您不會在操作系統級別累積技術債務。 讓這成為每周的習慣而不是偶爾的瑣事，則讓您的開發工具、運行時依賴、系統庫對齊，而這種對齊性就是使跨平台C#開發變得可靠而非挫折的原因。

詳細的逐步演示，可觀看Tim Corey在他的YouTube頻道上的影片。