ヘッダー
RPMを構築することは、ソースからコンパイルするという意味ではありません。純粋にtarソースコードやバイナリと一緒に「zip」ファイルをRPMに再パッケージすることを意味します。
noarch私はしばらくの間ソースからRPMをRPMとして構築してきました。最近、バイナリを含むRPMを構築する必要がありましたが、これによっていくつかの懸念が生じました。
archnoarchRPMとRPMの間の要素を決定するベストプラクティスはありますか？特にバイナリでRPMを構築する場合。 RPMをインストールすると、コンパイルなしでファイルのみを抽出する純粋なソースコードにはnoarch許可されていますが、上記のようにバイナリパッケージングについていくつかの質問があります。archRPMは他のオペレーティングシステムのバージョンと互換性がありますか？（これは上記の前文の文脈にあります。）もう少し詳しく説明すると、archRedHat 6でRPMを構築してからRedHat 5にインストールできますか？それともその逆も可能ですか？
答え1
実際にソースからビルドしたり、既存のアーカイブをパッケージ化することは重要ではありません。
noarchRPMはアーキテクチャ中立に設計されています。つまり、（ネイティブ）バイナリを含めないでください。
パッケージが解釈されたスクリプト（Bash、Pythonなど）、ドキュメント、ヘッダー、メディアファイルなど、またはコンパイルされたJavaクラスで構成されている場合は、次のことができます。ノッチ。同じパッケージには、特定のアーキテクチャ用に特別に構築されたコードが含まれていないため、すべてのハードウェアアーキテクチャで動作します。
一方、パッケージにネイティブマシンコード（C、C ++、Pascalなどで書かれたプログラムなど）でコンパイルされたバイナリが含まれている場合は、含まれているものに関係なくアーキテクチャにバインドする必要があります。プログラムは次のようにコンパイルされます。x86_64実行できませんパーソナルコンピュータたとえば、ホストオペレーティングシステムです。
さまざまなオペレーティングシステムのバージョンとの互換性は依存関係によって異なり、簡単に一般化することはできません。たとえば、パッケージが特定のライブラリの最小バージョンに依存している場合、そのライブラリの以前のバージョンを持つシステム（またはそのようなライブラリがまったくないシステム）で動作するという保証は明らかではありません。依存関係がない場合、または非常に一般的な依存関係がある場合は機能できます。
また、厳密に言えば、これは両方に適用されます。アーチそしてノッチバッグ。