RPMをビルドするときにArch対noarchを使用するのはいつですか？
序文
RPMをビルドするということは、ソースコードからコンパイルすることを意味しません。純粋に、tarまたは「Zip」ファイルをソースコードまたはバイナリとともに取得し、RPMとして再パッケージすることを意味します。
私はしばらくの間、noarch RPMとしてソースコードからRPMをビルドしています。最近、私はいくつかの懸念を引き起こしているバイナリを含むRPMを構築しなければなりませんでした：
ArchとnoarchRPMsの間のファクターを決定するためのベストプラクティスはありますか？特にバイナリファイルからRPMを構築する場合。コンパイルがなく、RPMのインストール時にファイルを抽出するだけの純粋なソースコードの場合、noarchは許容されますが、上記のように、バイナリのパッケージ化に関しては疑問があります。ArchRPMはさまざまなOSバージョンと互換性がありますか？（これは上記の序文のコンテキストにあります）詳述するために、RedHat 6にArchRPMをビルドしてからRedHat 5にインストールできますか？
実際には、ソースからビルドするか、既存のアーカイブをパッケージ化するかは、実際には重要ではありません。
noarch RPMはアーキテクチャに依存しないことを意味します。つまり、RPMは（ネイティブ）バイナリを含んではなりません。
パッケージが解釈済みスクリプト（Bash、Pythonなど）、ドキュメント、ヘッダー、メディアファイルなどで構成されている場合、コンパイルされたJavaクラスでも、 noarch。特定のアーキテクチャ用に特別にビルドされたコードが含まれていないため、同じパッケージはどのハードウェアアーキテクチャでも機能します。
一方、パッケージにネイティブマシンコードにコンパイルされたバイナリ（C、C++、Pascalなどで記述されたプログラムなど）が含まれている場合は、他に何が含まれていても、それらをアーキテクチャに関連付ける必要があります。 x86_64用にコンパイルされたプログラムは、たとえばppcホストOSでは実行できません。
異なるOSバージョンとの互換性については、依存関係によって異なり、簡単に一般化することはできません。たとえば、パッケージが特定のライブラリの最小バージョンに依存している場合、そのようなライブラリの古いバージョンを備えたシステム（またはそのようなライブラリをまったく備えていないシステム）での動作は保証されません。依存関係がないか、非常に一般的な依存関係がある場合は、動作する可能性があります。
また、厳密に言えば、これはArchおよびnoarchパッケージの両方に適用されます。