☰

rpm エミュレーション - 複雑な rpm ビルド

tag-icon • tag-icon rpm rpm-spec mock
rpm エミュレーション - 複雑な rpm ビルド

独自のOpenSSLを備えたApache Webサーバーを提供するRPMを作成したいとします。

/mydir/apache_postfix1
/mydir/openssl_postfix1

configure --prefix=/mydir/opensslmakeApache mod_sslには実際のOpenSSLインストールが必要なので、Apacheが実際にコンパイルできるようにOpenSSLをインストールする必要がありました。make install/mydir/opensslmod_sslconfigure --with-ssl=/mydir/openssl

これは、作業ディレクトリの外部に対する権限がないため、ビルドサーバー（Jenkins）では考えられないことです。ただし、OpenSSLを使用してApacheを構築し、それをRPMにパッケージ化する必要があります（それぞれ独自のOpenSSLを持つサフィックスを複数のApacheを提供する場合）。

だから私はこれがmock解決策だと思います（ユーザー/インストール権限を取得するよりもビルドサーバーにインストールする可能性が高いです）。

しかし、モックを使用してrpmbuildの完全な機能を使用する方法の完全なドキュメントを見つけることができませんでした。

試してみましたが失敗しているようmock -r epel-7-x68_64 example.src.rpmです/builddir/build/SPECS/example.spec。なぜですか？このファイルはどこからインポートされますか？

これは単なる例であり、実際の問題は、単一のサービスとして機能するように互いに構成/コンパイルする必要があり、Red Hat Satelliteを200を超えるサーバーに配信するために単一のRPMにパッケージ化する必要がある7つの個別のパッケージで構成されています。 ..実際にビルドサーバーにインストールせずに...

利用可能なドキュメント/サンプルに関するヘルプやリンクをお寄せいただきありがとうございます。

答え1

最良のドキュメントソースは次のとおりです。シミュレーションソースコード、これ公式rpmドキュメント、これrpm パッケージングガイドそして推奨される追加文書。公開した例では、example.src.rpmシミュレーションを使用できるようにパッケージの正しい場所に適切な仕様ファイルがないようです。

シミュレーションはsrc.rpmファイルの入力として再構築するか、仕様ファイルとソースディレクトリを使用してソースrpm（SRPM）を構築できます。一部の追加設定では、ソースコードチェックアウトで直接モックオブジェクトを使用することもできます。偽装をインストールしてそれを使用するようにユーザーを構成した後は、（rootとして使用しようとすると偽装が苦情を示し、権限のないユーザーは偽装グループに存在する必要があります）、使用は非常に簡単です。

yumdownloader --source openssl
mkdir rpm-results
mock -r epel-7-x68_64 --resultdir=rpm-results openssl-*.src.rpm

これにより、OpenSSLを提供するディストリビューションが再構築され、結果のパッケージがrpm-resultsディレクトリに配置されます。ディストリビューションで提供されるパッケージを変更するには、src.rpmをインストールして変更し、結果のrpmファイルをビルドする必要があります。

yumdownloader --source openssl
rpm -ivh openssl-*.src.rpm
# usually this installs to ~/rpmbuild
# make your changes to ~/rpmbuild/SOURCES/* and ~/rpmbuild/SPEC/openssl.spec as necesary
mkdir rpm-results
mock -r epel-7-x68_64 --resultdir=rpm-results --buildsrpm ~/rpmbuild/SPEC/openssl.spec
mock -r epel-7-x68_64 --resultdir=rpm-results rpm-results/openssl-*.src.rpm

最新バージョンに2段階のビルド（SRPM => RPM）が必要ないかどうかはわかりませんが、これが私たちの店でモデルを使用する方法です。再構築したいパッケージごとに、この作業を希望するか実行する必要があります。私はあなたが要求するようにすべてを1つのパッケージにまとめることをお勧めしませんが、技術的にはそうすることを防ぐことはできません。独自の仕様ファイルを作成し、すべてを一緒に組み合わせるか、次のような他のツールを使用します。フルオロメチルメタクリレート。

答え2

私はMockの管理者なので、答えをしたいと思います。しかし、正確に問題が何であるかを指定していないので、本当にできません。

私はMockがどのように機能するかについてのみ詳細に説明し、あなたの混乱を解決することができます。

呼び出すときはモックしてくださいmock -r fedora-27-x86_64（退屈な詳細は省略）。

  1. dnf install --installroot /var/lib/mock/fedora-27-x86_64/root @buildsys-buildこれにより、別のディレクトリに最小システムがインストールされます。この答えでは$ CHROOTと呼びます/var/lib/mock/fedora-27-x86_64/root。

  2. シミュレーションはexample.src.rpm。$CHROOT/builddir/build/SPECS$CHROOT/builddir/build/SOURCES

  3. Mockは仕様ファイルを解析し、BuildRequiresにリストされているすべてのパッケージを$ CHROOTにインストールします。 （これはrootとして行われます）。

  4. その後、Mockは$ CHROOTとしてchroot（）し、そこで実行されますrpmbuild -ba /builddir/build/SPECS/example.spec。これは、権限のないユーザー（UIDがあなたのUIDと同じ）で行われます。これは rpmbuild の実行は常に推奨されず、深刻な問題を引き起こす可能性があるために行われます。

したがって、chrootにいくつかの追加パッケージをインストールするには、yum / dnf installを呼び出してspecファイルからインストールしないでください（特にrpmは再入口ではないため）。ただし、BuildRequiresでこれらのパッケージを指定し、これらのパッケージを含むリポジトリを提供する必要があります。

mockchain -a REPOS（モックチェーンはモックチェーンの上にある薄い層です）を使用するか、以下を介してリポジトリを提供できます。

cp /etc/mock/fedora-27-x86_64.cfg ~/my-custom-fedora-27-x86_64.cfg
#add your repository to ~/my-custom-fedora-27-x86_64.cfg
mock -r ~/my-custom-fedora-27-x86_64.cfg example.src.rpm

互いに依存する7つのsrc.rpmパッケージがある場合、最良のアプローチはmockchain 1.src.rpm 2.src.rpm .... 7.src.rpm結果の一時記憶域を作成しますwhile at-least-one-package-build do another loop。

実際の問題が何であるかを指定してください。

関連情報