C# 開発者向け Linux パッケージの更新

Tim Corey

8分25秒

LinuxでC#アプリケーションを開発するとき、あなたのシステムパッケージはOS以上に影響を与えます。 Webアプリのテストのためのブラウザエンジン、.NET SDK、共有ライブラリ、およびセキュリティパッチはすべてパッケージマネージャーを介して提供されます。 古いパッケージを実行すると、ビルドの問題、脆弱性、または最新 for .NET機能と互換性がなくなることがあります。

彼のビデオ"C# DevelopersのためのLinuxパッケージの更新"では、Tim CoreyがLinuxインストールを最新の状態に保つ方法をグラフィカルなUpdate Managerとコマンドラインの両方を使用して、その広範なC# on Linuxシリーズの一部として案内します。 この記事では、両方の方法をカバーし、それぞれのコマンドが実際に何をするのかを解説し、また、.NET開発のためにシステムを最新に保つことがなぜ重要であるかを説明します。

Linuxパッケージ管理がWindowsと異なる点

[0:00 - 0:38] TimはWindowsからの開発者に共通のつまずきの要点に着目して始めます。 Windowsでは、通常各アプリケーションが独自に更新を管理します。 Visual StudioはEdgeとは独立して更新を確認し、プリンタードライバとは別に更新されます。 すべてがインストールされているものを追跡する単一のシステムはありません。

Linuxは集中型のアプローチを取っています。 apt（Advanced Package Tool）などのパッケージマネージャーが、公式リポジトリからインストールされたすべてのソフトウェアを追跡します。 更新を実行すると、aptはインストールされたすべてのパッケージに対してリポジトリを一度にクエリします。 ブラウザ更新、ライブラリパッチ、SDKアップグレード、セキュリティ修正がすべて同じパイプラインを通じて届きます。

C#開発者にとって、これは実際の影響があります。 あなた for .NETランタイム、HTTPS呼び出しが依存するOpenSSLライブラリ、およびアプリケーションがリンクするシステムレベルの依存関係はすべてこのシステムによって管理されています。 初めて非WindowsプラットフォームでC#を学び始めているなら、パッケージマネージャーの動作を理解することで、後になって神秘的なビルドの失敗を追いかける必要がなくなります。 単一のapt upgradeはスタック全体を整列させ続け、Windows上で多くの個別のアップデーター全体で調整する必要があることをします。

GUI：アップデートマネージャー

[0:38 - 1:34] ビジュアルなワークフローを好む開発者のために、Timは初めにアップデートマネージャーを案内します。Linux MintにはWindows Updateによく似たものが含まれています。 タスクバーの右下の小さなアイコンをクリックして開くと、何が更新されるのかを正確に確認できます：Microsoft Edge、Firefox、curl、libssh、その他です。 各項目には現在のバージョン、新バージョン、およびダウンロードサイズが表示されます。

すべてのパッケージがデフォルトで選択されていますが、特定の更新をスキップしたい場合は項目をチェック解除することもできます。 プロジェクトに特定のバージョンが必要であり、スプリントの途中で変更を避けたい場合に便利です。

"更新をインストール"をクリックして、プロンプトが出たらパスワードを入力し、処理が完了するのを待ちます。 パスワードのプロンプトは、システムパッケージを変更することが管理的な操作であるため存在します。これについては次のセクションでカバーします。

GUIがうまくやることの1つ：更新をリスクレベルで分類し、システムの安定性に影響を及ぼす可能性のある変更についてより慎重です。 Linuxに不慣れな開発者が詳細を気にせずに環境を健全に保ちたい場合、Update Managerは堅実なデフォルトです。

sudoの理解

[1:34 - 1:51] ターミナルに移動する前に、Timがsudoについて説明します。これは、すべてのコマンドラインパッケージ操作に現れるためです。 タイピングを始める前にそれが何をするのかを理解する価値があります。 ほとんどのWindowsユーザーアカウントはデフォルトで管理アカウントで、システムソフトウェアをインストール、削除、変更するフルアクセスがあります。 Linuxは逆のアプローチを取ります：あなたのアカウントは限られた権限で動作し、必要なときにのみ管理権限に昇格します。

コマンドの前にsudoを付けると、身元を確認するためのパスワードプロンプトがトリガーされます。 一度認証されると、そのコマンドはルート権限で実行され、それから権限が通常に戻ります。 パッケージ管理（ソフトウェアのインストール、削除、または更新）はシステムレベルの操作であり、マシン上のすべてのアプリケーションに影響を与える可能性があるため、明示的なsudoプレフィックスは、他のことをしようとしてシステムパッケージを誤って変更しないようにします。

Windowsを使ったことがあっても、それを管理者としてVisual Studioを実行することと同様と考えることができますが、Linuxではアプリケーション全体よりも個々のコマンドを昇格させます。 それはよりターゲットを絞ったモデルです。

コマンドライン：apt update

[1:51 - 2:28] sudoがカバーされると、Timはターミナルに移ります。 そこで作業することで、更新プロセスに対してより詳細な制御が可能になり、彼は3つのコマンドを順に案内します。 彼が指摘しているように、名前の付け方が誤解を招きやすいため、各コマンドが何をするのかを理解することが重要です。

最初のコマンドは次の通りです：

sudo apt update

sudo apt update

このコマンドはパッケージを更新するという一般的な仮定があります。 それはそうではありません。 apt updateはパッケージインデックス、利用可能なソフトウェアのローカルカタログをリフレッシュします。 経年によりメンテナが新しいバージョンをリリースするため、そのカタログが古くなるため、このコマンドを実行すると、リポジトリサーバーから最新バージョンをダウンロードします。 マシン上のソフトウェアに変更はありません。純粋に情報収集ステップです。

それを実行した後、aptは新しいバージョンが利用可能なパッケージの数を報告します。 何か変更を行う前に、フルリストを検査することができます。

apt list --upgradeable

apt list --upgradeable

これにより、利用可能な新バージョンがあるすべてのパッケージの行ごとのビューが得られ、現在のバージョンと新バージョンの数字が含まれます。 このマシンで.NETを扱っている場合、ここでSDKの更新、ランタイムパッチ、またはアプリケーションが依存するライブラリへの変更が見られるかもしれません。 あなたのマシンでど for .NETバージョンが動作しているかを理解することで、特定のアップグレードが安全に適用できるか、または最初にテストが必要かを決定するのに役立ちます。

コマンドライン：apt upgrade

[3:01 - 3:40] インデックスが更新されたら、Timは実際に新しいバージョンをインストールする2番目のコマンドに移ります：

sudo apt upgrade

sudo apt upgrade

命名に注意してください: upgradeはパッケージを変更します。 この2ステップ分割は意図的です。 "何が利用可能かをチェックする"ステップから"変更を適用する"ステップを分離することで、何かが動く前にレビュー、調査、またはバックアップの時間を与えます。

内部では、upgradeは何をするか、しないかについて厳格なルールに従います。 すでにシステム上にあるパッケージの新しいバージョンをダウンロードしインストールしますが、以前存在していなかった新しいパッケージを削除したりインストールしたりすることはありません。 新しいバージョンがインストールされていない依存関係を必要とする場合、upgradeはそのパッケージをそのままにして、新しい依存関係を自動的に引き入れません。

利点は予測可能性です。 あなた for .NETスタックを最新に保つことは重要ですが、制御された方法で行うことも同様に重要です。 システムは変更される内容の概要でプロンプトを表示し、何もあなたの明示的な許可なしには起こりません。

コマンドライン：apt full-upgrade

[3:40 - 4:19] 安全な更新が適用された状態で、Timはupgradeによって意図的に保留されたすべてのものを処理するための3番目のコマンドを紹介します。

sudo apt full-upgrade

sudo apt full-upgrade

upgradeが意図的に避けるケースを処理します。 パッケージの更新が新しい依存関係のインストールや競合するパッケージの削除を必要とする場合、full-upgradeがそれを実行します。 カーネルのアップグレード、主要なシステムライブラリの変更、およびOSレベルのパッチはここで適用されます。

これを別のステップとして実行することで、レイヤー化されたアプローチを提供します。 複雑な依存関係の解決中に何か問題が発生した場合、すでに簡単な更新を適用済みで、より関与するものをトラブルシューティングする必要があります。

LinuxでC#アプリケーションをコンパイルするビルドパイプラインを管理しているチームにとって、この段階的なワークフローは特に関係があります。 自動化されたCI/CD環境では、安定性のためにfull-upgradeをスケジュールされたメンテナンスウィンドウで使用して、深いシステム変更後にすべてがまだコンパイルされ、合格することを確認できます。

なぜパッケージ数が異なるのか

[2:28 - 3:01] 定期的に人々を混乱させるもの：Update Managerには23の更新が表示され、コマンドラインには79のパッケージが表示されるかもしれません。 これらは異なる更新セットではありません； 同じシステムが異なるカウント方法をしています。

GUIは関連するパッケージを論理単位にグループ化します。 Update Managerの1つの"Firefox更新"は実際にはFirefoxのバイナリ、ローカライゼーションパック、それが依存する共有ライブラリ、および構成パッケージで構成され、aptがそれぞれ別々のパッケージとして追跡します。 ですので、Update Managerが1つの更新として提示するものは、aptでは4つまたは5つの個別のパッケージアップグレードとしてリストされます。

これを知ってしまえば、矛盾することはなくなります。 誰かが"100個のパッケージをアップグレードする必要があった"と言うかもしれませんが、あなたのUpdate Managerが30の更新として表示しているのと同じ変更セットについてです。

Flatpak：別のパッケージマネージャー

[5:56 - 6:41] 見逃しやすい注意点があります：Linuxには複数のパッケージマネージャーがインストールされており、aptは管理しているパッケージのみを知っています。 Flatpakはそのような代替手段の1つです。それは、独自の依存関係を持つアプリケーションをサンドボックスベースのシステムでパッケージし、システムの他の部分と隔離されます。

Flatpakを通じてソフトウェアをインストールした場合、apt upgradeを実行してもそのアプリケーションには影響しません。 それらは別途更新する必要があります：

flatpak list
flatpak update

flatpak list
flatpak update

flatpak updateはそれらのパッケージを最新バージョンにします。 それを通してIDE、データベースツール、または通信アプリをインストールしているなら、定期的に確認することは良い習慣です。

Linuxでは、ソフトウェアはapt、Flatpak、Snap、または手動インストールを通じて到着することがあります。 それぞれが独自の更新メカニズムを持っているため、徹底した更新ルーチンはそれらすべてを考慮に入れる必要があります。 すべてのアプリケーションが独自のアップデーターを持っていることに慣れている場合、ここでの主な違いは、どのパッケージマネージャーがどのソフトウェアの一部を所有しているのかを知り、それぞれに適した更新コマンドを実行する必要があるということです。

どの方法を使用すべきですか？

[4:19 - 5:32] Timは、両方のアプローチが有効であり、正しい選択はワークフロー次第だと述べています。 ビジュアルインターフェイスに慣れている場合、Update Managerはポイントアンドクリックインターフェイスを通じてaptと同じ更新を処理します。 コマンドを暗記する必要はなく、間違った順序でステップを実行する心配もありません。 それとは別に、コマンドラインに慣れる理由は自動化です。 完全な更新シーケンスを実行し、週次で実行するようにcronにスケジュールする単純なシェルスクリプトを作成できます。 これにより、定期的な考慮の必要なくシステムを最新の状態に保つ3行のスクリプトは、長期的に見れば大きな価値を生む小さな投資です。

自動化を超えて、コマンドラインは文脈に応じて特定のアップグレードレベルを選択的に適用したり、出力を他のツールにパイプして分析することを可能にします。 これらのオプションはGUIでは利用できません。

インストールされたパッケージの監査

[7:16 - 7:54] 更新プロセスには役立つ副作用があります。それは、更新リストを確認することがシステムにインストールされているものの監査として機能することです。 更新キューにパッケージが表示された場合、それがまだ必要かどうか考える価値があります。

主にEdgeを使用しているときにFirefoxが更新リストに表示されたり、その逆もあります。 Webアプリケーションのクロスブラウザテストのために2つのブラウザをインストールしておくのは理にかなっていますが、広い意味では、更新リストは開発環境の全体像を露出します。 以前のプロジェクトからの古いツール、依存関係として引き込まれたがクリーンアップされていない開発ライブラリ、6か月前にインストールしたことを忘れたパッケージ：これらはすべてここに表示されます。

そのような整理整頓は期待以上に効果を発揮します。 クリーンな開発環境は、チームメンバー全体での再現が容易であり、コンテナ化が簡単であり、"私のマシンでは動く" というバグの発生可能性を減少させます。 LinuxマシンにDockerfileに含まれていないパッケージがインストールされている場合、本番環境に存在しないものに依存している可能性があります。 C# アプリケーションをDockerにデプロイすることに慣れることは、ローカルのパッケージと本番環境のつながりをより具体的にします。

結論

[7:54 - 8:25] Timが示しているように、Update Managerまたはコマンドラインを使用するかに関わらず、プロセス全体は数分で完了し、OSレベルでの技術的負債の蓄積から守ります。 週次の習慣にすることで、開発ツール、ランタイム依存関係、システムライブラリが整合し、それがクロスプラットフォームのC#開発を信頼できるものにします。

完全なステップバイステップのウォークスルーについては、Tim Coreyのビデオを彼のYouTubeチャンネルで確認してください。