根本的な問題については、私が知っているすべてのrpmバージョンに存在する2つの追加の解決策があるかもしれません。
- サブパッケージ
macro
およびrpmrc
ファイル。
サブパッケージ
別の代替手段(そしておそらく「RPMの方法」)は、サブパッケージを使用することです。Maximum RPMには、サブパッケージの情報と例もあります。
問題は、次のような構造を作ろうとしていると思います。
- 2つのスペックファイル。rpm_debug.specとrpm_production.specと言います
- 両方使用
%include common.spec
デバッグと本番環境は、クライアントやサーバーなどでもかまいません。変数を再定義する例では、各サブパッケージに独自の変数リストを含めることができます。
制限事項
サブパッケージの主な利点は、ビルドが1つだけ行われることです。これも不利になる可能性があります。デバッグと本番の例でこれが強調される場合があります。これは、strip
バリアントを作成するために使用するか、異なる出力で2回コンパイルすることで回避できます。おそらくVPATH
GnuMakeで使用します)。headers
大きなパッケージをコンパイルしてから、静的ライブラリなどの開発者情報の有無などの単純なバリエーションのみを用意する必要があるため、このアプローチを高く評価できます。
マクロとRpmrc
サブパッケージは、 rootfs階層全体、またはRPMのより大きなコレクションに必要な構造定義の問題を解決しません。私たちはこれのために持っています。とを実行するときとを変更することにより、大量の変数とマクロを定義できます。ページから、rpmbuild --showrc
rpmrc
macros
rpm
rpmbuild
man
rpmrc Configuration
/usr/lib/rpm/rpmrc
/usr/lib/rpm/redhat/rpmrc
/etc/rpmrc
~/.rpmrc
Macro Configuration
/usr/lib/rpm/macros
/usr/lib/rpm/redhat/macros
/etc/rpm/macros
~/.rpmmacros
これらの2つの機能は、可能なすべての問題を解決できると思います%include
。ただし、%include
これはおなじみの概念であり、rpmをよりフル機能で開発者にとって使いやすいものにするために追加された可能性があります。