序章

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

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

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

FPMのインストール

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

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

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機能に精通する

The 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

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

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

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

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)

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

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

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

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

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

ソースの種類 ソースの説明 ソース名または場所を渡す方法 追加のパッケージが必要
dir ディレクトリまたはファイル ローカルファイルシステム上のプロジェクトファイルの絶対パスまたは相対パスを渡します。 (無し)
タール tarballソースパッケージ ローカルファイルシステム上のtarball(圧縮または非圧縮)の場所へのパスを渡します。 (無し)
宝石 Rubyの宝石 www.rubygems.orgにあるRubygemの名前を渡します。 パッケージを作成するために自動ダウンロードされます。 ruby, rubygems-integration
Python Pythonパッケージ に渡すのと同じようにPythonパッケージの名前を渡します easy_install. 名前は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パッケージのローカルファイルシステム上の場所を渡します(これは、OSXシステムでのみ機能します。 pkgbuild 彼らの道に)。 pkgbuild (OS Xシステムでのみ使用可能)
(ソースなし) 実際のパッケージなしでパッケージを作成するために使用されます。 これは、依存関係のみを含むメタパッケージに最もよく使用されます。 (無し)
デブ A .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用のパッケージファイル。 OSXのインストールで作業している必要があります pkgbuild これらのパッケージを作成するためにインストールされます。 pkgbuild (OS Xシステムでのみ使用可能)
ソラリス Solarisシステムへのインストールに適したパッケージ。 絶対必要です pkgprotopkgmk インストール済み。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 インフラストラクチャ全体で使用するパッケージを作成しようとするとき、またはプロジェクトの公的にダウンロード可能なパッケージを配布するときに、作業が楽になります。 ポリシー上の懸念から、実際のディストリビューションのリポジトリをパッケージ化するための理想的なソリューションではないかもしれませんが、その利点は多くのシナリオで魅力的です。