前書き
Linuxのさまざまなディストリビューションで使用されているパッケージ形式は、簡単に使用できる方法でプロジェクトをリリースしたいソフトウェア開発者にとっての苦痛のポイントになる可能性があります。 DebianとUbuntuは `+ .deb `パッケージに依存していますが、FedoraとRedHatは両方とも ` .rpm +`スタイルのパッケージシステムを使用しています。 これらは互換性がなく、それらを作成するために必要なツールは、それぞれの離心率に不慣れな人にとっては作業がかなり難しい場合があります。
ディストリビューションのパッケージメンテナーは公式リポジトリに含まれるパッケージの面倒な作業を行いますが、自分のサイトでこれらのディストリビューションのソフトウェアをリリースする予定がある場合、または組織用のパッケージを作成する必要がある場合、通常はパッケージを自分で提供する必要があります。 これには、従来、各パッケージファミリの少なくともいくつかのツールの仕組みを学ぶことが含まれていました。
このプロセスの複雑さを最小限に抑えるために、「+ fpm 」というツールが作成されました。 ` fpm `を使用すると、利用するパッケージングツールのコマンドを知らなくても、 ` .deb `ファイルと ` .rpm `ファイルの両方を簡単に作成できます。 このガイドでは、 ` fpm +`を使用してUbuntu 14.04サーバーを使用してさまざまな形式のパッケージを作成する方法について説明します。
FPMのインストール
`+ fpm `ツール自体の主な配布方法は、Ruby gemです。 Ruby開発パッケージと、追加のソフトウェアをコンパイルするために必要なソフトウェア構築ツールの両方をインストールすることで、システムに「 fpm +」をインストールする準備を整えることができます。
まず、ローカルパッケージキャッシュを更新してから、前提条件のインストールに進みます。
sudo apt-get update
sudo apt-get install ruby-dev build-essential
上記のパッケージをインストールしたら、次のように入力して `+ fpm +`パッケージ自体を取得できます。
sudo gem install fpm
これにより、システムレベルで「+ fpm +」がインストールされ、システム上のすべてのユーザーが利用できるようになります。 従来のパッケージングの常識では、パッケージを通常の非ルートユーザーとして作成することをお勧めします。 これは、システムに影響する可能性のあるパッケージングエラーの場合により安全です。
これで、システムで「+ 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 -t
ソースには、さまざまなタイプがあります。 ソースタイプは、ソース名または場所がコマンドに渡される方法も決定します。 次のセクションでは、可能な入力形式と出力形式について説明します。
一部の形式では、変換するために個々のパッケージタイプに関連付けられた追加のヘルパーユーティリティをインストールする必要があります。 `+ fpm `を動作させるためにすでにRubyの必須コンポーネントをインストールしているため、Ubuntuシステムを使用しているため、Ruby gemファイルを ` .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のリストを確認すると、Bundlerが利用可能になっていることがわかります。
gem list
*** LOCAL GEMS ***
arr-pm (0.0.9)
backports (3.6.0)
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 +`ツールは、かなりの数の異なるソースおよびターゲット形式で動作します。 これらにはそれぞれ独自の要件と機能があります。
フォーマット(Ruby gemファイルのrubygems.orgなど)に対してオンラインで比較的標準的なパッケージインデックスがある場合、 `+ fpm +`は自動的にインデックスを検索し、必要なファイルをダウンロードできます。 最初に現在のディレクトリで一致するものを検索し、ローカルの一致が見つからない場合はインデックスを検索します。
現在、次のソースタイプがサポートされています。
Source Type | Source Description | How to Pass Source Name or Location | Additional Packages Needed |
---|---|---|---|
dir |
Directory or files |
Pass the absolute or relative path(s) of the project files on the local filesystem. |
(none) |
tar |
A tarball source package |
Pass the path to the location of the tarball (compressed or uncompressed) on the local filesystem. |
(none) |
gem |
A Ruby gem |
Pass the name of a Ruby gem that can be find on www.rubygems.org. It will be auto-downloaded to create the package. |
|
python |
A Python package |
Pass the name of a Python package as you would pass it to |
|
pear |
A PHP extension |
Pass the name of a PHP extension or application found on pear.php.net. The appropriate files will be auto-downloaded when creating the package. |
|
cpan |
A Perl module |
Pass the name of a Perl module as found at cpan.org. The files will be auto-downloaded and used to build the package. |
|
zip |
A zipped directory structure |
Pass the location on the local filesystem of a zip file containing the package. |
|
npm |
A Node.js module |
Pass the name of a Node module as specified on npmjs.org. The package will be auto-downloaded and used to make the output package. |
|
osxpkg |
An OS X package |
Pass the location on the local filesystem of an OS X package (this will only work on OS X systems with |
|
empty |
(no source) |
Used to create a package without any actual packages. This is used most often for meta-packages that only contain dependencies. |
(none) |
deb |
A |
Pass the location of a |
(none on Debian-based systems) |
rpm |
An |
Pass the location of an |
|
また、作成したいターゲットのパッケージング形式には、かなりの数のオプションがあります。 次の表に、さまざまなオプションの一部を示します。
Output Type | Output Description | Additional Packages Needed |
---|---|---|
deb |
A Debian-style package that can be installed on Debian or Ubuntu systems. |
(none on Debian-based systems) |
rpm |
A RedHat-style package that can be installed on CentOS, Fedora, or RedHat systems. |
|
zip |
A zip file containing the directory and file structure of the input package. |
|
tar |
A tarball (compressed or uncompressed) of the directory structure of the input package. |
(none) |
dir |
A directory in which to extract the inputted package. |
(none) |
sh |
A self-extracting |
(none) |
osxpkg |
A package file for OS X. You must be working on an OS X installation with |
|
solaris |
A package suitable for installing on a Solaris system. You must have |
|
pkgin |
A package suitable for installing on BSD systems. You must have the |
|
puppet |
A puppet module that can be used to install on various systems. (). |
(cannot test in non-working state) |
ご覧のとおり、ソースとターゲットの両方の仕様の一部の形式では、特定のオペレーティングシステムを使用する必要があります。 Ubuntu 14.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 *:適切なタイミングで実行する必要があるスクリプトファイル。
選択したパッケージ形式に固有のオプションもかなりあります。 完全なリストについては、ヘルプを確認してください。
パッケージのカスタマイズ
詳細をカスタマイズし、1つの形式を出力形式に直接変換したくない場合は、別のワークフローを採用する必要があります。
このプロセスは、従来のパッケージングをもう少し厳密に反映しますが、複数の出力形式を迅速に生成できるという利点も提供します。 問題のアプリケーションが標準の +。/ configure +
、 + make +
、 `+ make install +`コンパイルおよびインストールプロセスを使用していると仮定して、以下の一般的なワークフローを示すことができます。
最初に、パッケージに必要なすべての依存関係をインストールします。 次に、Webサイトからプロジェクトのソースパッケージを取得し、作業ディレクトリに配置します。
mkdir ~/build
cd ~/build
wget
これで、ファイルを抽出し、結果のディレクトリに変更できます。
tar xzvf .tar.gz
cd
このディレクトリ内に、パッケージ化するアプリケーションのソースファイルがあります。 これで、ファイルを調整したり、オプションを設定したりできます。
ビルドプロセス中にオプションを指定する通常の方法は、付属の `。/ configure +`スクリプトを使用することです。 プロジェクトのドキュメントを参照して、使用可能なコンパイルオプションを確認してください。 オプションで ` configure +`スクリプトを呼び出すことでそれらを指定できます:
./configure --= --= -- ...
これにより、パッケージのビルド時に `+ make +`コマンドによって読み取られるファイルが作成または変更されます。 次のように入力して、実際のインストールファイルを作成できます。
make
システムで設定したこれらのファイルをインストールする代わりに、実際のパッケージを構築できる空のダミーディレクトリにインストールします。 パッケージをインストールするディレクトリを作成します。
mkdir -p /tmp/
`+ DESTDIR `オプションを ` make install +`に渡すことで、この新しいディレクトリにルートインストール場所としてラベルを付けることができます。
make DESTDIR=/tmp/ install
これで、パッケージは空のスケルトンディレクトリにクリーンインストールされました。 必要なすべてのディレクトリ構造を作成しましたが、そのディレクトリ内のパッケージに関係のないものはありません。
これは、セットアップをカスタマイズする2番目の機会です。 インストールのために階層に追加のファイルを含める場合は、この構造内の適切な場所にそれらを追加できます。
準備ができたら、 `+ fpm `を使用して適切なパッケージファイルを作成できます。 たとえば、 ` fpm +`コマンド内でバージョン情報とパッケージの説明を渡すことができます。 依存関係情報をリストしたり、パッケージングメタファイルの作成に影響する追加の詳細を提供することもできます。
ディレクトリ構造を使用して、複数のパッケージング形式を構築できます。 たとえば、次のように入力して `+ .deb +`パッケージを作成できます。
fpm -s dir -t deb -C /tmp/ --name --version --iteration --depends --description "A sample package" .
これにより、現在のディレクトリに「+ project-name_1.0.0-1_amd64.deb +」というパッケージが作成されます。
その後、いくつかのオプションを変更して、 `+ .rpm `パッケージを作成できます(リポジトリから ` rpm +`パッケージをインストールした場合):
fpm -s dir -t -C /tmp/project --name project_name --version 1.0.0 --iteration 1 --depends --description "A sample package" .
これにより、現在のディレクトリに「+ project_name-1.0.0-1.x86_64.rpm +」というパッケージが作成されます。
ご覧のとおり、 `+ fpm +`を使用してカスタマイズしたパッケージを作成するのはかなり簡単です。 困難なタスクのほとんどは依然としてツールによって処理されます。
結論
`+ fpm +`を使用すると、インフラストラクチャ全体で使用するパッケージを作成しようとするとき、またはプロジェクトのパブリックにダウンロード可能なパッケージを配布するときに、人生が楽になります。 ポリシー上の懸念から、実際のディストリビューションのリポジトリのパッケージングには理想的なソリューションではないかもしれませんが、多くのシナリオでその利点は魅力的です。