Linuxディストリビューションについて私が理解したことによれば、アップデートの通知を受け取り、簡単なクリックまたは複数のコマンドを使用してアップデートをインストールします。これは、以前にインストールしたソフトウェアのパッチ更新またはマイナーバージョンの更新です。たとえば、ディストリビューションでは、Firefoxバージョン23をFirefoxバージョン24にアップグレードすることをお勧めします（悪い例、マイナーバージョンではありませんが、アイデアを得る可能性があります）。ただし、数ヶ月後にアップグレードするように求められます。インストールしたパッケージではなく、システム自体を更新することです。
他のソフトウェアパッケージと同様に、小規模で継続的なアップデートでシステム自体をアップデートできないのはなぜですか？
この問題を解決するために、ローリングリリースではどのソリューションが使用されますか？
ベストアンサー1
他のソフトウェアパッケージと同様に、小規模で継続的なアップデートでシステム自体をアップデートできないのはなぜですか？
ご存知のように、一部のディストリビューションはこのように動作します。アップグレードプロセスは本質的に一連のアップデートです。 「システム自体のアップデート」と「インストールされたパッケージではない」の区別は少し不正確です。はい今インストールしたパッケージです。各種展開可能アップグレードにのみ適用される明確な基準がいくつかありますが、これがこのアプローチを使用する理由ではないと思います。バージョンアップを使用するための特別な技術的な理由はまったくないと思いますが、既存のバージョン管理リリースをローリングリリースに変換するのに時間がかかりすぎると思います。
最大の理由は区画化だと思います。バージョン2では、一連の元に戻す調整だけでは達成できないバージョン1の重要な変更が必要になる場合があります。したがって、バージョン 2 の開発中は、バージョン 2 で動作しないバージョン 1 を維持する必要がある場合があります。ほぼみんなこれが実際のソフトウェアが実行される方法です。 AFAIK、それは単なるソフトウェアです。分散ローリングリリースモデルを使用してください。
さらに、最初にV.2が重大な失敗であることが判明した場合、ユーザーは以前のバージョンを使用することを好むでしょう。これは確かにLinuxディストリビューションに適用されるロジックです。
この問題を解決するために、ローリングリリースではどのソリューションが使用されますか？
まあ、彼らはパッケージにバージョンコントロールを使用します。前述のようにシステムが良いので良いです。ただバッグ。インストールされているすべてはパッケージの一部であるため、システムの修正はいくつかのパッケージを全体的に変更する問題です。
バージョン指定されたリリースでは、パッケージには実際にはパッケージバージョンとリリースバージョンという2つのバージョンが関連付けられます。たとえば、whatever.1.2.3その展開用のパッケージの複数の同時バージョンを見つけることができます。私はこれがリリース間の「画期的な変更」と呼ぶことにかなりの柔軟性を提供すると思います。いずれにせよ、1.2.3は同じアップストリーム（ソース）ソースから来ることができますが、リリース1に関連する重要なアーキテクチャの変更を反映するように、リリース2では異なる構成にすることができます。