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

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

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

内部的に、upgrade は行うべきことと行わないべきことに関して厳密なルールに従います。 すでにシステム上にあるパッケージの新しいバージョンをダウンロードしインストールしますが、以前存在していなかった新しいパッケージを削除したりインストールしたりすることはありません。 新しいバージョンが未インストールの依存関係を必要とする場合、upgrade はそのパッケージを保留にします。

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

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

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

sudo apt full-upgrade

sudo apt full-upgrade

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

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

LinuxでC#アプリケーションをコンパイルするビルドパイプラインを管理しているチームにとって、この段階的なワークフローは特に関係があります。 自動化された CI/CD 環境 では、安定性を保つために apt upgrade だけを実行し、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 list コマンドは Flatpak 経由でインストールされたすべてを表示し、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チャンネルで確認してください。