FPMを使用して複数の形式のパッケージを簡単に作成する方法

序章

Linuxのさまざまなディストリビューションで使用されているパッケージ形式は、プロジェクトを簡単に消費できる方法でリリースしたいソフトウェア開発者にとっては問題になる可能性があります。 DebianとUbuntuは.debパッケージに依存していますが、FedoraとRedHatはどちらも.rpmスタイルのパッケージシステムを使用しています。これらは互換性がなく、それらを作成するために必要なツールは、それぞれの偏心に慣れていない人にとっては、操作がかなり難しい場合があります。

ディストリビューションのパッケージメンテナは、公式リポジトリに含まれるパッケージの手間をかけますが、これらのディストリビューションのソフトウェアを自分のサイトでリリースする予定がある場合、または組織のパッケージを作成する必要がある場合は、通常、自分でパッケージを提供する必要があります。これには、従来、パッケージングファミリごとに少なくともいくつかのツールの動作を学習することが含まれていました。

このプロセスの複雑さを最小限に抑えるために、fpmというツールが作成されました。 fpmを使用すると、使用するパッケージツールのコマンドを知らなくても、.debファイルと.rpmファイルの両方を簡単に作成できます。このガイドでは、fpmを使用して、Ubuntu14.04サーバーを使用してさまざまな形式のパッケージを作成する方法について説明します。

FPMのインストール

fpmツール自体の主な配布方法は、Rubygemとしてです。追加のソフトウェアをコンパイルするために必要なRuby開発パッケージとソフトウェアビルドツールの両方をインストールすることで、システムにfpmをインストールする準備をさせることができます。

まず、ローカルパッケージキャッシュを更新してから、前提条件のインストールを続行します。

sudo apt-get update
sudo apt-get install ruby-dev build-essential

上記のパッケージをインストールしたら、次のように入力してfpmパッケージ自体を取得できます。

sudo gem install fpm

これにより、fpmがシステムレベルにインストールされ、システム上のすべてのユーザーが利用できるようになります。従来のパッケージングの知恵では、root以外の通常のユーザーとしてパッケージを作成することをお勧めします。これは、システムに影響を与える可能性のあるパッケージエラーの場合に安全です。

これで、システムでfpm実行可能ファイルを使用できるようになります。これは、ツールの豊富なヘルプ情報を確認することで確認できます。

fpm --help

Intro:

  This is fpm version 1.2.0

  If you think something is wrong, it's probably a bug! :)
  Please file these here: https://github.com/jordansissel/fpm/issues

  You can find support on irc (#fpm on freenode irc) or via email with
  [email protected]

Usage:
    fpm [OPTIONS] [ARGS] ...
. . .

これで、パッケージの作成を開始できます。

基本的なFPM機能に精通する

fpmツールは、パッケージのビルドを完了するために何が必要かを伝えるのにかなり優れています。最も基本的な要件を理解するために、引数なしでコマンドを呼び出すことができます。

fpm

Missing required -s flag. What package source did you want? {:level=>:warn}
Missing required -t flag. What package output did you want? {:level=>:warn}
No parameters given. You need to pass additional command arguments so that I know what you want to build packages from. For example, for '-s dir' you would pass a list of files and directories. For '-s gem' you would pass a one or more gems to package from. As a full example, this will make an rpm of the 'json' rubygem: `fpm -s gem -t rpm json` {:level=>:warn}
Fix the above problems, and you'll be rolling packages in no time! {:level=>:fatal}

この出力は、パッケージを作成するために提供する必要があるものの基本を示しています。一般的な呼び出しは、基本的な形式では次のようになります。

fpm -s source_type -t target_type source_name_or_location

ソースは、いくつかのタイプのいずれでもかまいません。ソースタイプは、ソース名または場所がコマンドに渡される方法も決定します。次のセクションでは、可能な入力形式と出力形式について説明します。

一部の形式では、変換するために、個々のパッケージタイプに関連付けられた追加のヘルパーユーティリティをインストールする必要があります。 fpmを機能させるためにRubyEssentialsをすでにインストールしており、Ubuntuシステムを使用しているため、Rubygemファイルを.debパッケージに変換できるはずです。

bundlerのような一般的に使用される宝石を選びましょう。 rubygems.orgにあるbundlerパッケージから、次のように入力して.debパッケージを作成できます。

fpm -s gem -t deb bundler

Created package {:path=>"rubygem-bundler_1.6.5_all.deb"}

rubygem-bundler_1.6.5_all.debというファイルがローカルディレクトリに作成されました（バージョン番号が異なる場合があります）。これで、他の.debパッケージと同じようにこれをインストールできます。

sudo dpkg -i rubygem-bundler_1.6.5_all.deb

インストールされているgemのリストを確認すると、バンドラーが利用可能になっていることがわかります。

gem list

*** LOCAL GEMS ***

arr-pm (0.0.9)
backports (3.6.0)
bundler (1.6.5)
cabin (0.6.1)
childprocess (0.5.3)
clamp (0.6.3)
ffi (1.9.3)
fpm (1.2.0)
json (1.8.1)

別のソースまたは出力フォーマットを簡単に使用することもできますが、フォーマットを変換するには、システムにいくつかの追加ツールが必要です。これについては後で説明します。

ソースとターゲットのフォーマット

fpmツールは、かなりの数の異なるソースおよびターゲット形式で動作します。これらにはそれぞれ独自の要件と機能があります。

あるフォーマット（Rubygemファイルのrubygems.org など）の比較的標準的なパッケージインデックスがオンラインにある場合、fpmはインデックスを自動的に検索し、必要なものをダウンロードできます。ファイル。最初に現在のディレクトリで一致するものを検索し、次にローカルの一致するものが見つからない場合はインデックスを調べます。

現在、次のソースタイプがサポートされています。

ソースの種類	ソースの説明	ソース名または場所を渡す方法	追加のパッケージが必要
dir	ディレクトリまたはファイル	ローカルファイルシステム上のプロジェクトファイルの絶対パスまたは相対パスを渡します。	（無し）
タール	tarballソースパッケージ	ローカルファイルシステム上のtarball（圧縮または非圧縮）の場所へのパスを渡します。	（無し）
宝石	Rubyの宝石	www.rubygems.orgにあるRubygemの名前を渡します。パッケージを作成するために自動ダウンロードされます。	`ruby`、`rubygems-integration`
Python	Pythonパッケージ	`easy_install`に渡すのと同じように、Pythonパッケージの名前を渡します。名前はPythonPackageIndexで検索され、自動ダウンロードされてパッケージが作成されます。	`python-setuptools`
梨	PHP拡張	pear.php.netにあるPHP拡張機能またはアプリケーションの名前を渡します。パッケージの作成時に、適切なファイルが自動ダウンロードされます。	`php-pear`
cpan	Perlモジュール	cpan.orgにあるPerlモジュールの名前を渡します。ファイルは自動ダウンロードされ、パッケージのビルドに使用されます。	`cpanminus`
ジップ	zip形式のディレクトリ構造	パッケージを含むzipファイルのローカルファイルシステム上の場所を渡します。	`zip`
npm	Node.jsモジュール	npmjs.orgで指定されているノードモジュールの名前を渡します。パッケージは自動ダウンロードされ、出力パッケージの作成に使用されます。	`npm`
osxpkg	OSXパッケージ	OS Xパッケージのローカルファイルシステム上の場所を渡します（これは、パスに`pkgbuild`が含まれるOSXシステムでのみ機能します）。	`pkgbuild`（OS Xシステムでのみ使用可能）
空	（ソースなし）	実際のパッケージなしでパッケージを作成するために使用されます。これは、依存関係のみを含むメタパッケージに最もよく使用されます。	（無し）
デブ	`.deb`パッケージ	ローカルファイルシステム上の`.deb`ファイルの場所を渡します。	（Debianベースのシステムではなし）
rpm	`.rpm`パッケージ	ローカルファイルシステム上の`.rpm`ファイルの場所を渡します。	`rpm`

作成したいターゲットパッケージ形式には、かなりの数のオプションもあります。次の表に、さまざまなオプションのいくつかを示します。

出力タイプ	出力の説明	追加のパッケージが必要
デブ	DebianまたはUbuntuシステムにインストールできるDebianスタイルのパッケージ。	（Debianベースのシステムではなし）
rpm	CentOS、Fedora、またはRedHatシステムにインストールできるRedHatスタイルのパッケージ。	`rpm`
ジップ	入力パッケージのディレクトリとファイル構造を含むzipファイル。	`zip`
タール	入力パッケージのディレクトリ構造のtarball（圧縮または非圧縮）。	（無し）
dir	入力したパッケージを抽出するディレクトリ。	（無し）
sh	自己解凍型の`.sh`ファイル。これは、実行時に抽出されるbzipされたtarファイルを含むシェルスクリプトです。	（無し）
osxpkg	OSX用のパッケージファイル。これらのパッケージを作成するには、`pkgbuild`がインストールされたOSXインストールで作業している必要があります。	`pkgbuild`（OS Xシステムでのみ使用可能）
ソラリス	Solarisシステムへのインストールに適したパッケージ。 `pkgproto`と`pkgmk`がインストールされている必要があります。これらは、Solarisマシンでのみ使用できます。	`pkgproto`、`pkgmk`（Solarisシステムでのみ使用可能）
pkgin	BSDシステムへのインストールに適したパッケージ。 `pkg_create`パッケージをインストールする必要があります。これは、BSDシステムでのみ使用できます。	`pkg_create`（BSDシステムでのみ使用可能）
傀儡	さまざまなシステムにインストールするために使用できるパペットモジュール。（注：この形式は、現在のバージョンのfpm では正しく機能しません）。	（非動作状態ではテストできません）

ご覧のとおり、ソース仕様とターゲット仕様の両方の形式の中には、特定のオペレーティングシステムを使用している必要があるものがあります。このツールはUbuntu14.04でデモンストレーションしているため、osxpkgソース形式、およびosxpkg、solaris、およびpkgin出力形式は使用できません。

オプションを使用したFPMの動作の変更

上記のセクションの表の情報を使用すると、fpmのデフォルト設定を使用していくつかの基本的なパッケージを作成できるはずです。ただし、ほとんどの場合、結果のパッケージを形成するために、いくつかの追加情報を提供する必要があります。

元のパッケージの場所または名前を指定するソース引数の前に、オプションを指定する必要があります。

多くのfpmで利用可能なさまざまなオプションがあります。以下では、より一般的なもののいくつかのみを取り上げます。完全なリストについては、fpm --helpコマンドを確認してください。

使用する可能性のある一般的なオプションは次のとおりです。

-C ：ファイルを探す前に変更するディレクトリを指定します。
–prefix ：結果のパッケージ内のファイルがインストールされる場所を指定するディレクトリパス。
-p ：パッケージのパッケージ名とパス。これにより、結果のパッケージファイルのファイル名を上書きできます。
-n ：パッケージに使用する名前。これは、プラットフォームのパッケージツールに表示される名前です。
-v ：パッケージに使用するバージョン番号。
–iteration ：パッケージのリリース情報。この番号のディストリビューションの名前はさまざまですが、通常は、アプリケーションのバージョンではなく、パッケージのバージョンを追跡する方法です。
–license ：パッケージのライセンス名。これには、パッケージのメタデータにライセンスタイプが含まれますが、パッケージ自体に関連するライセンスファイルは含まれません。
–category ：このパッケージが属するカテゴリ。これは、リポジトリ内のパッケージを整理するために使用できます。
-d ：これは、パッケージの依存関係を指定するために複数回使用できます。
–provides ：これは、このパッケージが提供するシステム機能を指定するために使用できます。これは通常、要件を満たすために複数の選択肢がある場合に使用されます。
–conflicts ：インストールしてはならないパッケージを指定するために使用されます。
–replaces ：このパッケージのインストール時に削除する必要があるパッケージを指定するために使用されます。
–config-files ：パッケージ内のファイルを構成ファイルとしてマークするために使用されます。通常、パッケージマネージャーは、パッケージが削除されたときにこれらをそのまま残します。
–directories ：ディレクトリをパッケージが所有しているものとしてマークします。
-a ：パッケージのアーキテクチャを指定します。
-m ：パッケージメンテナフィールドを上書きします。デフォルトでは、このフィールドにusername@hostが使用されます。
-e ：パッケージをビルドする前に、スペックファイルを手動で確認および編集します。これは、パッケージ仕様に使用されているデフォルトのいずれかを微調整するために使用できます。
–description ：パッケージの説明を設定します。
–after-install 、 –before-install 、 –after-remove 、 –before-remove ：実行する必要のあるスクリプトファイル適切な時期に。

選択したパッケージ形式に固有のオプションもかなりあります。完全なリストについては、ヘルプを確認してください。

パッケージのカスタマイズ

詳細をカスタマイズしたいが、あるフォーマットを出力フォーマットに直接変換したくない場合は、別のワークフローを採用する必要があります。

このプロセスは、従来のパッケージングをもう少し厳密に反映しますが、複数の出力形式を迅速に生成できるという利点も提供します。問題のアプリケーションが標準の./configure、make、make installのコンパイルおよびインストールプロセスを使用していると仮定して、以下の一般的なワークフローを示すことができます。

まず、パッケージに必要なすべての依存関係をインストールします。次に、プロジェクトのソースパッケージをWebサイトから取得し、作業ディレクトリに配置します。

mkdir ~/build
cd ~/build
wget http://example.com/project.tar.gz

これで、ファイルを抽出して、結果のディレクトリに変更できます。

tar xzvf project.tar.gz
cd project

このディレクトリ内に、パッケージ化するアプリケーションのソースファイルがあります。これで、ファイルを微調整し、いくつかのオプションを構成する機会があります。

ビルドプロセス中にオプションを指定する通常の方法は、付属の./configureスクリプトを使用することです。プロジェクトのドキュメントをチェックして、使用可能なコンパイルオプションを確認してください。オプションを指定してconfigureスクリプトを呼び出すことにより、それらを指定できます。

./configure --compilation_option=value --another_option=value --optional_flag ...

これにより、パッケージのビルド時にmakeコマンドによって読み取られるファイルが作成または変更されます。これで、次のように入力して実際のインストールファイルを作成できます。

make

システムに構成したこれらのファイルをインストールする代わりに、実際のパッケージを構築できる空のダミーディレクトリにインストールします。パッケージをインストールするディレクトリを作成します。

mkdir -p /tmp/project

DESTDIRオプションをmake installに渡すことにより、この新しいディレクトリにルートインストール場所のラベルを付けることができます。

make DESTDIR=/tmp/project install

これで、パッケージが空のスケルトンディレクトリにきれいにインストールされました。必要なディレクトリ構造はすべて作成されていますが、そのディレクトリ内のパッケージに関係のないものはありません。

これは、セットアップをカスタマイズする2番目の機会です。インストールのために階層に追加のファイルを含める場合は、この構造内の適切な場所にそれらを追加できます。

準備ができたら、fpmを使用して適切なパッケージファイルを作成できます。たとえば、fpmコマンド内でいくつかのバージョン情報とパッケージの説明を渡すことができます。また、依存関係情報を一覧表示したり、パッケージ化メタファイルの作成に影響を与える追加の詳細を提供したりすることもできます。

ディレクトリ構造を使用して、複数のパッケージ形式を作成できます。たとえば、次のように入力して、.debパッケージを作成できます。

fpm -s dir -t deb -C /tmp/project --name project_name --version 1.0.0 --iteration 1 --depends debian_dependency1 --description "A sample package" .

これにより、現在のディレクトリにproject-name_1.0.0-1_amd64.debというパッケージが作成されます。

次に、いくつかのオプションを変更して、.rpmパッケージを作成できます（リポジトリからrpmパッケージをインストールしたと仮定します）。

fpm -s dir -t rpm -C /tmp/project --name project_name --version 1.0.0 --iteration 1 --depends  redhat_dependency1 --description "A sample package" .

これにより、現在のディレクトリにproject_name-1.0.0-1.x86_64.rpmというパッケージが作成されます。

ご覧のとおり、fpmを使用してカスタマイズされたパッケージを作成するのはかなり簡単です。難しいタスクのほとんどは、ツールによって処理されます。

結論

fpmを使用すると、インフラストラクチャ全体で使用するパッケージを作成しようとするとき、またはプロジェクトの公的にダウンロード可能なパッケージを配布するときに、作業が楽になります。ポリシー上の懸念から、実際のディストリビューションのリポジトリをパッケージ化するための理想的なソリューションではないかもしれませんが、その利点は多くのシナリオで魅力的です。