新しいバージョンにアップグレードするときに、ほとんどのディストリビューション(Debian以外)が完全な再インストールを推奨/要求するのはなぜですか?


10

私のLinux生活のほとんどをDebianを使って過ごしてきたので、他のディストリビューションを見ていて、バージョン間のスムーズなアップグレードを提供していないことに本当に驚いています。Debianは無限にアップグレード可能であり、私はいくつかの主要な安定バージョンを使ってアップグレードしました。

私はFedora(および派生物)のようなよくサポートされたディストリビューション、Ubuntuと派生物についてさえ話している。CentOSのような安定したサーバー指向のディストリビューションでさえ。

それは、Debianのパッケージ管理システムとパッケージアップグレードスクリプトが、他のディストリビューションが提供するものよりもはるかに進んでいるためですか?

または、ディストリビューションに関係なく、メジャーバージョンアップグレードを最初から再インストールすることは、全体的に良いアイデアですか?

回答:


6

これは、いくつかの要因の組み合わせです。

ほとんどのディストリビューションでは、重大な、場合によっては重大な変更を実装する時期としてメジャーリリースを使用しています。たとえば、Fedora 15はsystemdを追加し、Ubuntuは6.10でupstartを追加しました。Debianは多くの点で非常に保守的なディストリビューションです。大規模で重大な変更は避けられます。

たとえば、Debianのリリースサイクルは、新しいリリースの標準を満たすためにすべての重要なパッケージを変更する必要があるため、非常に離れています。

Debianのパッケージ管理技術は、FedoraやUbuntuよりも優れているわけではありませんが(明らかに、Ubuntuと同じであるため)、Debianは文化的に、円滑なアップグレードシステムを備えることが重要であると判断しました。


5
より正確には、彼らは何をすることを決めていない運用サーバーにしたいことは、その上にソフトウェアをアップグレードするには、最初からそれを再インストールする必要があります。
Shadur 2012

Fedoraを使用している場合でも、インストーラー介して(シングルバージョン)アップグレード実行すると、可能であれば、基盤となるインフラストラクチャの変更に関してDTRTが試行されます。
Ignacio Vazquez-Abrams 2012年

1

より具体的に言うと、アップグレードを行うときに多くのディストリビューションで問題が発生しました。Ubuntuたとえば、インストールパッケージベースはリリース間で大幅に変更されています。従来の「dist-upgrade」を実行すると、インストールされたパッケージは新しいリリースに更新されますが、最終的な結果には新しいラインナップの変更がありません。デフォルトのインストールからのパッケージが降格された場合、「サポートされる」またはさらに悪い「サポートされない」だけに、そのパッケージを保持します。新しいパッケージがデフォルトのインストールに含まれている場合、そのパッケージはインストールされません。リリースが「技術的に」アップグレードされたリリースであっても、新しいリリースのエクスペリエンスは反映されません。同じケースも非常に正確です。CentOS5とCentOS6を比較すると、パッケージ名が完全に再編成されています。

Debianは、そのような大幅な変更を犠牲にして、スムーズなアップグレードを優先します。Debianの新しい機能が遅いのはこのためです。彼らのコミュニティにとって、トレードオフは許容範囲です。前の答えを繰り返しますが、それはパッケージ管理技術自体とは何の関係もありません。言うまでもなく、Ubuntuの定期的な再インストールは身に着けています。


Ubuntuには、アップグレード用の特別なツールが含まれており、dist-upgradeが行う以上のことを行うと考えられています。あなたはそれについてもっと知っていますか、それは良いことですか?
trr

1

あなたが述べていることは、ローリングリリースディストリビューションのファミリー全体には当てはまりません。

システムメンテナンスソフトウェアの場合、システムの一部のみをアップグレードする場合、またはアップグレード全体で構成の一貫性を維持する場合、パッケージ間の互換性の問題を解決することははるかに困難です。さまざまなソフトウェアパッケージを相互に適切に連携させる必要があります。

そのため、システムアップデートを提供する最も簡単な(つまり、同じ開発時間で最も信頼できる)ソリューションは、完全にテストされた完全なインストールリリースを定期的に準備することです。Red Hatなどのエンタープライズソリューションは、クライアントに信頼性の高いシステムを提供する必要があり、アップグレードをできるだけ長く中断することによって問題が発生する必要があるという立場を取ります。(もちろん、マイナーなアップグレードとバグ修正が利用可能であるか、自動的にプルされる必要があります)。これは、CentOSなどの無料サーバーディストリビューションの背後にある一般的な哲学でもあります。

リリース間でシームレスなアップグレードルートをエンドユーザーに提供することは、システム開発者にとって大きな課題です。多くのディストリビューションは、これまでの時間を犠牲にしないことを選択しています。多くの一般的なパッケージ(QTなど)はアップグレードが難しく、完全な再インストールが必要になることがよくあります。さらに重要なことは、多くのプロジェクトが開発努力の減少を示すか、そうでなければ新しいテクノロジーに取って代わられることです。システムパッケージの場合、多くの場合、システムの大幅な再設計が必要になります。移行手順は、バージョンCからDにアップグレードしたいという人もいれば、フォームBまたはAから、あるいは途中でカスタム状態から切り替える人もいるという事実を考慮に入れる必要がある場合は、実装が特に難しい場合があります。

したがって、すでにご想像のとおり、最も難しいアプローチはローリングリリースです。私はDebianのアプローチの詳細を知りませんが、あなたの説明から、彼らは真ん中のどこかにあることがわかります。


Debianは以前の安定版から現在の安定版へのアップグレードを完全にサポートしています。それらは2〜3年離れているため、glibc、KDE ​​3から4、次のGnome 2から3などの主要な移行が含まれます。一部のパッケージはアップグレードが難しく、再インストールする必要があると言われています-これは既知ですDebian内では「主要な移行」として、パッケージマネージャーはこれらを完全に管理でき、エンドユーザー向けに完全にテストおよびサポートします。私はあなたが主張するよりもマインドセットについてやるべきことはもっとたくさんあると思います-Debianはそれがそれに取り組むための正しい方法であると信じているので、彼らはそれを実現します。
trr
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.