%20%E3%81%A7%E3%81%AF%E3%80%81%E6%96%B0%E3%81%97%E3%81%84%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%82%B0%E3%83%AC%E3%83%BC%E3%83%89%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AB%E5%AE%8C%E5%85%A8%E3%81%AA%E5%86%8D%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%82%92%E6%8E%A8%E5%A5%A8%2F%E8%A6%81%E6%B1%82%E3%81%99%E3%82%8B%E3%81%AE%E3%81%A7%E3%81%97%E3%82%87%E3%81%86%E3%81%8B%3F.png)
私は Linux ライフのほとんどを Debian を使って過ごしてきましたが、他のディストリビューションも見てきましたが、バージョン間のスムーズなアップグレードが提供されていないことに本当に驚いています。Debian は無制限にアップグレード可能で、私はこれまでにいくつかの主要な安定バージョンをアップグレードしました。
私が言っているのは、Fedora (および派生版)、Ubuntu および派生版など、十分にサポートされているディストリビューションです。CentOS のような安定したサーバー指向のディストリビューションも含まれます。
それは、Debian のパッケージ管理システムとパッケージ アップグレード スクリプトが、他のディストリビューションが提供するものよりもはるかに先進的だからでしょうか?
それとも、ディストリビューションに関係なく、メジャー バージョン アップグレード時に最初から再インストールする方が全体的に良いアイデアなのでしょうか?
答え1
それはいくつかの要因の組み合わせです。
ほとんどのディストリビューションでは、メジャー リリースを、重要な、場合によっては破壊的な変更を実装するタイミングとして使用します。たとえば、Fedora 15 では systemd が追加され、Ubuntu では 6.10 で upstart が追加されました。Debian は、多くの点で非常に保守的なディストリビューションです。大きな破壊的な変更は好まれません。
その結果、たとえば Debian のリリース サイクルは非常に離れています。これは、すべての重要なパッケージを新しいリリースの標準に合わせて変更する必要があるためです。
Debian のパッケージ管理技術は Fedora や Ubuntu のものより優れているわけではありません (当然、Ubuntu のものと同じなので) が、Debian は文化的に、スムーズなアップグレード システムを持つことが重要であると判断しました。
答え2
もっと具体的に言うと、私はアップグレードを行う際に多くのディストリビューションで問題に遭遇しました。たとえば、Ubuntu はリリース間でインストール パッケージ ベースを大幅に変更します。従来の「dist-upgrade」を実行すると、インストールされたパッケージは新しいリリースに更新されますが、最終結果には新しいラインナップの変更がありません。デフォルト インストールのパッケージが降格されて単に「サポート対象」になったり、さらに悪いことに「サポート対象外」になったりしても、そのパッケージは保持されます。新しいパッケージが現在デフォルト インストールに含まれている場合、そのパッケージはインストールされません。リリースが「技術的に」アップグレードされたリリースであっても、新しいリリース エクスペリエンスが反映されません。同じケースも非常に正確で、CentOS5 と CentOS6 を比較すると、パッケージ名が完全に再編成されています。
Debian は、このような大幅な変更を犠牲にして、スムーズなアップグレードを優先しています。これが、Debian が新機能に対して遅い理由ですが、コミュニティにとってはそのトレードオフは許容範囲です。前の回答を繰り返すと、これはパッケージ管理技術自体とはまったく関係ありません。Ubuntu の頻繁な再インストールは、私にとっては負担になっています。
答え3
あなたが述べていることは、ローリングリリース配布。
システム メンテナンス ソフトウェアの場合、システムの一部のみをアップグレードする場合や、アップグレード全体にわたって構成の一貫性を維持する場合に、パッケージ間の互換性の問題を解決することは非常に困難です。さまざまなソフトウェア パッケージを、互いにうまく動作するように調整する必要があります。
だからこそ、最も簡単な(つまり同じ開発時間で最も信頼性が高い) システム アップデートを提供するためのソリューションは、完全で徹底的にテストされたフルインストール リリースを定期的に準備することです。Red Hat などのエンタープライズ ソリューションは、クライアントに信頼性の高いシステムを提供し、アップグレードによる中断をできるだけ長く許容する必要があるという立場をとっています (もちろん、マイナー アップグレードとバグ修正は利用可能であるか、自動的にプルされる必要があります)。これは、CentOS などの無料サーバー ディストリビューションの背後にある一般的な哲学でもあります。
エンド ユーザーにリリース間のシームレスなアップグレード ルートを提供することは、システム開発者にとって大きな課題です。多くのディストリビューションは、このために貴重な時間を犠牲にしないことを選択しています。多くの人気パッケージ (たとえば QT など) はアップグレードが難しく、完全な再インストールが必要になることがよくあります。さらに重要なことは、多くのプロジェクトで開発作業が減少したり、新しいテクノロジに置き換えられたりしていることです。システム パッケージの場合、これには多くの場合、大幅なシステム再設計が必要です。一部のユーザーはバージョン C からバージョン D にアップグレードしたいが、他のユーザーはバージョン B またはバージョン A から、あるいは途中のカスタム状態から切り替えるという事実を考慮する必要がある場合は、移行手順の実装が特に困難になる可能性があります。
したがって、すでにご想像のとおり、最も難しいアプローチはローリング リリースです。Debian のアプローチの詳細はわかりませんが、あなたの説明から、その中間にあることがわかります。