パッケージ用にRPMリポジトリを1セット使用するRPMベースのディストリビューション(Fedoraなど)がインストールされており、別のRPMリポジトリセットを使用するように変更して別のディストリビューション(CentOSなど)に効果的に変換したいと思います。システムを再インストールせずにこれを行う必要があります。
私がこれをしたいのは、私たちの組織でこのコンピュータを私に与え、「ここに別のオペレーティングシステムをインストールしないでください」という指示を受けたからです。しかし、セキュリティ更新プログラムを受信するのにかなり遅いように見える曖昧なストレージセットを使用しており、ストレージが正しく維持されているかどうかは本当に信頼できません。私はコンピュータへのルートアクセス権を持っており、IT部門によると、これは「再インストール」とは見なされません。
ただし、このリポジトリのパッケージにはベンダーサフィックスが付いたバージョン名があります(たとえば、Ubuntuのパッケージにはバージョンがあります1:13.0.1-2ubuntu2
)。特に、一部のシステムパッケージにはsystemd
これらの機能があります。 AFAICT、これはシステム自体systemd
だけでなく、依存しているすべてを再systemd
インストールする必要があることを意味するため、システムの実行中にシステムの大部分が削除され、再インストールされます。これはインストールを中断する非常に迅速な方法のようです。 。
私が考慮した可能な解決策の1つは、インストール依存関係ツリーの葉から始まります
- 新しいリポジトリから適切なパッケージをダウンロードします。
- 依存関係のバージョンが古いリポジトリのバージョンと一致するように編集します。
- 既存のパッケージの上にこのパッケージをインストールします。
- このパッケージが他のパッケージに依存している場合は、編集されていないバージョンに置き換えてください(このパッケージは新しい名前を持ち、編集されたパッケージは以前の名前によって異なります)。
- 依存関係ツリーの深さごとにこの操作を順番に実行します。
この戦略は効果的ですか?このタイプのアップグレードを実行するには、他のどのオプションが必要ですか?
答え1
この部分を
2ubuntu2
バージョン番号と呼びます。これは、パッケージマネージャが同じバージョンの2つのパッケージバリアントを比較するために使用されます。パッケージマネージャはそれを純粋に英数字として扱います。他の意味はありません。この部分をubuntu2
dist-tagと呼びます。パッケージがどのシステムに適しているかを人々が理解するのに役立ちます。ただし、パッケージマネージャはこの値を評価しません。 RHEL9には「el5」パッケージをインストールし、RHEL5には「el9」パッケージをインストールできます。多くの場合、梱包要件により中断される可能性があります。ただし、パッケージに他の依存関係がない場合は、そうすることができます。このアプローチには問題はありません。RPMパッケージは、新しいパッケージをインストールしてから古いパッケージを削除することによってアップグレードされます。このようにしても、
dnf upgrade
システムは常に実行する必要があります。取引中でも。依存関係が複雑すぎるため、パッケージを1つずつアップグレードすることはほとんど不可能です。大きな仕事でより良い幸運を享受します。
CentOSからファイルをインポートして
/etc/yum.repos.d
コンピュータに配置し、操作を実行または/etc/yum.repos.
実行するdnf upgrade
こともできます。dnf distro-sync
成功する確率は80%だと思います。しかし残りの20%はひどい。より良い場合は、トランザクションの前に依存関係が破損します。どういうわけか問題を解決することができます。最悪の場合、取引中にいくつかのエラーが発生します。すべてがクラッシュして起動できないシステムが発生します。事前に推測するのは難しいです。問題はおそらくあなたがこの仕事をする人が世界で初めてであるということです。これらのパイオニアは間違いを発見します。
この作業を行うために生産機械を使用することは非常に躊躇しています。少なくとも同じ構成の一部の仮想マシンでは、まずこのアップグレードパスを試してください。