説明すると、私は私たちの会社のいくつかの製品を32ビットから64ビットに更新する仕事を担当しています。
結局、私たちは64ビットカーネル+ 32ビットアプリケーション+いくつかの64ビットアプリケーションを持っています。この場合、私たちは主に依存関係であるいくつかのrpmの32ビット版と64ビット版が必要だと推測しましたが、依存関係を使い始めた後は状況が少し悪化しました。
64ビットのProgram1というプログラムが1つだけあり、システムの残りの部分は32ビットであるとします。このプログラム1にはlibgccが必要です。システムで作業を実行する前に、実際のlibgccバージョンを照会します。
$>rpm -qa --queryformat '%{NAME}.%{ARCH}\n' | grep libgcc
応答は次のとおりです。
$>libgcc.i386
私は64ビットlibgcc rpmをインストールしに行きました:
$>rpm -ivh --force --ignorearch libgcc-4.3.2-7.x86_64
しかし、今はクエリした後
$>rpm -qa --queryformat '%{NAME}.%{ARCH}\n' | grep libgcc
2つではなく1つだけ受け取りました。
$>libgcc.x86_64
ファイルを確認すると、ライブラリとプログラムが期待どおりに実行されるため、両方のバージョンで共通のインフラストラクチャを更新するまで問題はありません。
それでは、commonlibraries.i386.rpmやcommonlibraries.x86_64.rpmなどの新しい共通パッケージがあると想像してください。
commonlibraries.i386をアップグレードするにはlibgcc.i386が必要です。x86_64を更新した後に見られるように、1つのアーキテクチャだけが報告されるため、アップグレードプロセスは失敗します。
興味深いことに、私のワークステーションでは両方のバージョンを入手できます。
$ rpm -qa --queryformat '%{NAME}.%{ARCH}\n' | grep libgcc
libgcc.x86_64
libgcc.i686
しかし、私たちの製品では、複数のアーキテクチャで同じパッケージを使用することは不可能に見えます(これはlibgccなどの一部のパッケージでは発生しますが、kerberos5-librariesなどの他のパッケージでは発生しません)。過去にこの問題を経験したマスターがありましたか?
私はこれを読んだhttps://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=380441rpm -e --justbd --nodeps PackageNameを実行し、後でrpmをインストールしますが…動作しません。
答え1
結局、私たちは64ビットに切り替えました。この問題は、実際の32〜64ビットの問題ではなく、以前のディストリビューションのパッケージングの問題のようです。
libgccを強制せずにインストールしようとすると、post_libgcc_upgradeなどの%postマクロセクションの一部のバイナリと競合します。したがって、32〜64ビットの競合rpmパッケージごとに32ビットパッケージが「失われます」。
結局のところ、私はrpmパッケージとそのスクリプトセットから完全な依存関係を取得し、競合するファイルの異なる名前を持つ独自のrpmパッケージを作成し、それに応じてスクリプトを変更しました。すべての情報を収集し、正しくテストするのに数日かかりましたが、それほど価値がありました。
とにかく、これが誰かに役立つ可能性があるため、私が採用したソリューションを公開しました。