rpmベースのLinuxディストリビューション用のライブラリパッケージの構築

私たちのプロジェクトの多くは、オープンソースのライブラリを使用しています。 特定のプラットフォームで開発を行う場合、新しい開発者がプロ​​ジェクトに接続するたびにソースから同じライブラリを収集しても意味がありません。 さらに、 make && sudo make install



ライブラリmake && sudo make install



は、RPMパッケージマネージャデータベースに情報がない「所有者なし」ファイルでシステムが詰まっているため、悪い形式と見なされます。



ソリューションとして、コンパイル済みライブラリからRPMパッケージをコンパイルし、すべての開発者がアクセスできる単一のリポジトリに保存することをお勧めします。 以下は、パッケージを構築するための手順といくつかのヒントです。



この手順はRed Hat Enterprise Linux 6の例に基づいていますが、わずかな変更を加えて他のディストリビューションに適合させることができます。 たとえば、zeromqライブラリからパッケージを収集します。



パッケージを組み立てる前に



アセンブリする前に最初に行うことは、必要なパッケージがあなたの前に誰かによって収集されていないことを確認することです。 多くの場合、 rpmfind.netrpm.pbone.netなどのリソースで、必要なものを見つけることができます。 ただし、必要なバージョンのライブラリが見つからなかった場合、またはプラットフォーム用のアセンブリがない場合は、パッケージを自分でアセンブルする必要があります。



rpmbuild


パッケージは、 rpmbuildユーティリティを使用してビルドされます。 使用する前に、アセンブリの環境を構成する必要があります。 〜/ rpmbuildディレクトリなどに、必要なディレクトリツリーを作成します。



 $ mkdir ~/rpmbuild $ mkdir ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
      
      





rpmbuildユーティリティ構成ファイルを作成して、作成されたディレクトリツリーの場所を見つけます。



 $ echo '%_topdir %(echo $HOME)/rpmbuild' >~/.rpmmacros
      
      





rpmbuildは 、起動時に〜/ rpmbuild / BUILDROOT / <package_name>ディレクトリでパッケージファイルを探します。 zeromqの例を使用して、RPMパッケージの命名方法を見てみましょう。



zeromq-3.2.4-1.rhel6.x86_64.rpm







ここに:



パッケージ名のフィールドを区切る文字に注意してください。 これらは例とまったく同じでなければなりません。



そのため、BUILDROOTにzeromqのディレクトリを作成します。



 $ mkdir ~/rpmbuild/BUILDROOT/zeromq-3.2.4-1.rhel6.x86_64
      
      





図書館集会


もちろん、バイナリパッケージをアセンブルする前に、ライブラリ自体をコンパイルする必要があります。 ライブラリがGNU Autotoolsビルドシステムを使用している場合、これは通常次のコマンドで実行されます。



 $ ./configure $ make
      
      





次に、BUILDROOTで作成したディレクトリにライブラリをインストールします。



 $ make install DESTDIR="$HOME/rpmbuild/BUILDROOT/zeromq-3.2.4-1.rhel6.x86_64"
      
      





DESTDIRパラメーターは、メイクファイルで常に処理されるとは限りません。 たとえば、qmakeは、このパラメーターを無視するメイクファイルを生成します。 ライブラリがGNU Autotools以外のアセンブリシステムを使用している場合は、対応するマニュアルで、指定されたディレクトリにライブラリをインストールするためにアセンブリ中に渡す必要があるパラメータを読んでください。



パッケージをビルドするための仕様ファイル



RPMパッケージでは、アーカイブされたファイルツリーに加えて、このパッケージに関するメタ情報が保存されます。 アセンブリ中に、〜/ rpmbuild / SPECSフォルダーにあるspec-fileで指定する必要があります。 zeromqライブラリのサンプルzmq.specファイルを考えてみましょう。



 Name: zeromq Version: 3.2.4 Release: 1.rhel6 Summary: Software library for fast, message-based applications Packager: My organization Group: System Environment/libraries License: LGPLv3+ with exceptions %description The 0MQ lightweight messaging kernel is a library which extends the standard socket interfaces with features traditionally provided by specialized messaging middle-ware products. 0MQ sockets provide an abstraction of asynchronous message queues, multiple messaging patterns, message filtering (subscriptions), seamless access to multiple transport protocols and more. This package contains the ZeroMQ shared library for versions 3.x. %post /sbin/ldconfig %postun /sbin/ldconfig %files %defattr(-,root,root) /usr/lib64/libzmq.so.3 /usr/lib64/libzmq.so.3.0.0 %package devel Summary: Development files for zeromq3 Group: Development/Libraries Requires: %{name} = %{version}-%{release} %description devel The zeromq3-devel package contains libraries and header files for developing applications that use zeromq3 3.x. %files devel %defattr(-,root,root) /usr/include /usr/share /usr/lib64/pkgconfig /usr/lib64/libzmq.so /usr/lib64/libzmq.a /usr/lib64/libzmq.la
      
      





ファイルの先頭には、パッケージに関する情報を含むフィールドの最小セットが示されています。 パッケージの名前は、最初の3つのフィールド( NameVersionRelease )の値から形成されるため、正しい値がそこに示されることが重要です。 値が、ビルド中のパッケージのファイルツリーを含むディレクトリの名前と一致しない場合、rpmbuildはエラーをスローします。 Licenseフィールドも必須です。 ライセンスフィールドがないと、rpmbuildはパッケージのビルドを拒否します。



%descriptionセクションの目的は明らかです。 %postおよび%postunセクションには、パッケージファイルをシステムにインストールした後、およびパッケージファイルをシステムから削除した後に実行されるスクリプトがそれぞれ含まれています。 これは、パッケージが非標準ディレクトリに動的ライブラリ(.so)をインストールする場合(つまり、/ lib、/ usr / lib、/ lib64または/ usr / lib64にない場合)に便利です。 この場合、パッケージはldconfigの構成ファイルを提供し、/ etc / ld.so.conf.dにインストールする必要があります。 ldconfigコマンドは、構成ファイルで指定されたディレクトリで見つかったすべてのライブラリを追加することにより、ダイナミックローダーキャッシュを更新します。



%filesセクションには、rpmでパッケージ化されたファイルがリストされます。 %defattrディレクティブは、デフォルトのファイル属性を次の形式で指定します。



%defattr (<ファイルモード>、<ユーザー>、<グループ>、<ディレクトリモード>)



<ファイルモード>は8進数で指定します。たとえば、rw-r-r--の場合は「644」です。 <dir mode>属性は省略できます。 インストールされたファイルに対して変更すべきではない属性の代わりに、ハイフンを指定できます。 %filesセクションで指定されたディレクトリは、すべてのコンテンツとともにパッケージに含まれます。



その後、最も興味深い。 実際、ライブラリRPMパッケージには2つのタイプがあります。 それらの一部には、実際の動的ライブラリファイル自体が含まれています。これらは、これらのライブラリにリンクされているプログラムが機能するために必要です。 たとえば、zeromq-3.2.4-1.rhel6.x86_64.rpmパッケージは、/ usr / lib64 / libzmq.so.3.0.0とそのシンボリックリンクである/usr/lib64/libzmq.so.3の2つのファイルのみを提供します。 別のタイプのパッケージには、提供されたライブラリを使用してアプリケーションを開発するために必要なファイルが含まれています。 サフィックス「-devel」がそのようなパッケージの名前に追加されます(例:zeromq-devel-3.2.4-1.el6.x86_64.rpm)。 このようなパッケージには通常、C / C ++ヘッダーファイル、ドキュメント、静的ライブラリ(.a)が含まれており、これらのパッケージは最初のタイプのパッケージに依存しています。



上記のspecファイルでは、 %packageディレクティブを使用すると、rpmbuildを1回実行して「子」パッケージをビルドできます。 子パッケージのヘッダーフィールドの値は親から継承されますが、オーバーライドできます。 [ 必須]フィールドは、親パッケージへの追加の依存関係を指定します。 zeromq-develパッケージの%filesセクションには、ファイル/usr/lib64/libzmq.soが含まれていることに注意してください。 これは、実際の動的ライブラリファイルへのシンボリックリンクです。 ldリンカーは、「lib」で始まり「.so」で終わる動的ライブラリファイルを検索するため、ライブラリを使用するアプリケーションのビルド段階で必要になります。



組立



組み立てる前に留意すべきことが2つあります。

最初:パッケージを正常にビルドすると、rpmbuildはBUILDROOTディレクトリをクリアします。 念のため、パッケージ化されたファイルをバックアップしてください。

2番目:ルート権限でパッケージをコンパイルしないでください。 これを行うべきではない理由を説明します。



これで、パッケージをビルドする準備が整いました。 rpmbuildを実行します。



 $ cd ~/rpmbuild/SPECS $ rpmbuild -bb zmq.spec
      
      





-bbオプションは、「バイナリのビルド」、つまりバイナリパッケージのビルドを意味します。 バイナリパッケージに加えて、ソースパッケージもありますが、ここでは説明しません。



成功した場合、結果のrpmパッケージはRPMSフォルダーに保存されます。



いくつかのヒント



パッケージ化するライブラリのスペックファイルのヘッダーフィールドに何を書き込むべきかわからない場合は、上記のリソースから別の配布パッケージ用のRPMパッケージを取得し、そこに何が書かれているかを確認できます。



 $ rpm -qip package.rpm
      
      





ここで、「q」は「クエリモード」を意味し、「i」はパッケージに関する情報を受信することを意味し、「p」は指定されたパッケージファイルに関する情報を受信することを意味します(このオプションがなければ、システムにインストールされているパッケージに関する情報が受信されます) 。



どのファイルがdevelパッケージに属し、どのファイルがライブラリパッケージに属するかわからないが、別のディストリビューション用の両方のパッケージがある場合、このパッケージで提供されるファイルのツリーを現在のディレクトリに解凍できます。



 $ rpm2cpio package.rpm | cpio -di
      
      





rpm2cpioユーティリティは、rpmパッケージに保存されているcpioアーカイブを標準出力に書き込みます。 cpioユーティリティは、標準入力から受け入れられたアーカイブを解凍します。 パラメータ「i」は解凍モードを有効にし、「d」は必要なディレクトリを作成します。



「l」オプションを使用して、パッケージを展開することなく、パッケージが提供するファイルを確認できます。



 $ rpm -qlp package.rpm
      
      





合計



使用済みライブラリをRPMにパックすることにより、同僚がライブラリの必要なバージョンのソースコードを毎回ダウンロードする必要をなくし、アセンブリの問題(たとえば、ダウンロードしたライブラリソースにパッチを適用する必要がある場合)からそれらを保存し、一般的にライブラリを追加するプロセスを統一できますプロジェクトに。 この記事では、パッケージのアセンブルと仕様ファイルの作成(構成ファイル、ドキュメントなどの分離など)のすべての複雑さについては説明していませんが、ライブラリパッケージをアセンブルするために必要なことはありません。



All Articles