Difference between revisions of "Creating Packages (日本語)"

From ArchWiki
Jump to: navigation, search
m (update)
m (PKGBUILD とパッケージのテスト)
Line 150: Line 150:
 
== PKGBUILD とパッケージのテスト ==
 
== PKGBUILD とパッケージのテスト ==
  
As you are writing the {{ic|build()}} function, you will want to test your changes frequently to ensure there are no bugs. You can do this using the {{ic|makepkg}} command in the directory containing the {{ic|PKGBUILD}} file. With a properly formatted {{ic|PKGBUILD}}, makepkg will create a package; with a broken or unfinished {{ic|PKGBUILD}}, it will raise an error.
+
{{ic|build()}} 関数を記述している間、バグがないことを確認するために変更をテストしたくなるかもしれません。{{ic|PKGBUILD}} ファイルが含まれているディレクトリで {{ic|makepkg}} コマンドを実行してすることでテストすることができます。フォーマットが正しい {{ic|PKGBUILD}} なら、makepkg はパッケージを作成します。{{ic|PKGBUILD}} が壊れていたり未完成だと、エラーを吐きます。
  
If makepkg finishes successfully, it will place a file named {{ic|pkgname-pkgver.pkg.tar.xz}} in your working directory. This package can be installed with the {{ic|pacman -U}} command. However, just because a package file was built does not imply that it is fully functional. It might conceivably contain only the directory and no files whatsoever if, for example, a prefix was specified improperly. You can use pacman's query functions to display a list of files contained in the package and the dependencies it requires with {{ic|pacman -Qlp [package file]}} and {{ic|pacman -Qip [package file]}} respectively.
+
makepkg は問題なく終了すると、作業ディレクトリに {{ic|pkgname-pkgver.pkg.tar.xz}} という名前のファイルを作成します。このパッケージは {{ic|pacman -U}} コマンドでインストールすることがdけいます。ただし、パッケージファイルが作られたというだけでは完全に機能するとは言えません。あるいはディレクトリだけでファイルが全く含まれていない可能性もあります (例えば、prefix が間違って指定されているとか)。pacman の query 関数を使うことでパッケージに含まれているファイルのリスト、パッケージが必要とする依存パッケージを {{ic|pacman -Qlp [package file]}} {{ic|pacman -Qip [package file]}} でそれぞれ表示することができます。
  
If the package looks sane, then you are done! However, if you plan on releasing the {{ic|PKGBUILD}} file, it is imperative that you check and double-check the contents of the {{ic|depends}} array.
+
パッケージが問題ないようでしたら、これであなたの作業は終了です!ただし、{{ic|PKGBUILD}} ファイルを公開するつもりならば、{{ic|depends}} の中身を何度もチェックするべきです。
  
Also ensure that the package binaries actually ''run'' flawlessly! It is annoying to release a package that contains all necessary files, but crashes because of some obscure configuration option that does not quite work well with the rest of the system. If you are only going to compile packages for your own system, though, you do not need to worry too much about this quality assurance step, as you are the only person suffering from mistakes, after all.
+
また、パッケージバイナリが完璧に''動く''ことを確認しましょう!全ての必要なファイルが含まれているが、(システムの他の部分と問題を起こすような)度しがたい設定オプションによってクラッシュするパッケージを公開するのは迷惑です。勿論、あなた自身のためだけにパッケージをコンパイルするのなら、品質保証について心配しすぎる必要はありません。誤りによって苦しむのはあなただけなのですから。
  
 
===パッケージの正常性のテスト===
 
===パッケージの正常性のテスト===

Revision as of 15:18, 21 September 2013

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end

この記事は、Arch Linux の ports 風のビルドシステムを使ってパッケージを自作するユーザーの助けになることを目的としています。この記事の扱う範囲は PKGBUILD (makepkg によって読み込まれるパッケージ定義ファイル) の書き方についてです。すでに PKGBUILD が用意できている場合、makepkg の項目を参照してください。

概要

Arch Linux のパッケージは、makepkg ユーティリティーと PKGBUILD に記載された情報からビルドされます。makepkg が実行されると、カレントディレクトリの PKGBUILD を見て、ソースをコンパイルするか必要なファイルをダウンロードするかの指示に従ってパッケージファイル (pkgname.pkg.tar.xz) が作成されます。こうして出来上がったパッケージはバイナリとインストールの実行スクリプトが含まれ、pacman でインストールできるものになります。

Arch のパッケージは、以下のファイルが tar アーカイブ、つまり 'tarball' にまとめられ、xz で圧縮されたものです。

  • インストールするバイナリやファイル。
  • .PKGINFO: pacman でパッケージ管理や依存解決をするために必要なすべての情報が書かれたファイル。
  • .MTREE: ファイルのハッシュとタイムスタンプ。ローカルデータベースに含めることで pacman はパッケージの整合性を検証することができます。
  • .INSTALL: 任意のファイル。インストール/アップグレード/削除の後に実行される (PKGBUILD で指定された場合のみ存在する)。
  • .Changelog: パッケージメンテナによるパッケージの更新についての覚え書き (必ず付属するとは限らない)。

準備

ソフトウェアの準備

まず、必要なツールがインストールされているか確認してください。 base-devel があれば十分です。このグループには make などのコンパイルに必要なツールが含まれています。

# pacman -S base-devel

pacman で提供される makepkg はパッケージ作成で最も重要なツールの一つです。makepkg は以下を行います:

  1. 依存パッケージがインストールされているかどうか確認する。
  2. ソースをサーバーからダウンロードする。
  3. 圧縮されたソースファイルを展開する。
  4. fakeroot 環境でコンパイルし、インストールする。
  5. バイナリやライブラリから不要シンボルを除去する (symbol stripping)。
  6. パッケージのメタデータを生成する。
  7. fakeroot 環境をパッケージに圧縮する。
  8. パッケージファイルを出力先ディレクトリに保存する。デフォルトでは作業ディレクトリ。

インストールのダウンロードとテスト

パッケージにしたいソフトウェアのソース tarball をダウンロードして、展開してください。その後ソフトウェアの作成者の指示に従ってプログラムをインストールしてください。ソフトウェアをコンパイル・インストールするのに必要なコマンド・手順を全て手控えておきましょう。PKGBUILD ファイルの中で同じコマンドを使うことになります。

ほとんどのソフトウェアは3ステップでビルドします:

./configure
make
make install

プログラムが正しく動作するか確認すると良いでしょう。

PKGBUILDの作成

パッケージ作成に必要な情報は全て PKGBUILD に書かれています。makepkg は実行されると、カレントディレクトリに PKGBUILD ファイルがあるか探し、そこに書かれていることに従ってソフトウェアのソースコードをコンパイルします。PKGBUILD に書かれている指示は、Bash として実行可能である必要があります。コンパイルが無事終了すれば、出来上がったバイナリと、バージョンや依存パッケージなどのパッケージのメタデータが パッケージ名.pkg.tar.xz にまとめられます。このパッケージファイルは pacman -U パッケージファイル でインストールすることができます。

新しいパッケージを作るには、まず空の作業ディレクトリを用意します (~/abs/パッケージ名 が推奨です)。このディレクトリにファイル PKGBUILD を作成します。プロトタイプとして、/usr/share/pacman/PKGBUILD.proto や、類似パッケージの PKGBUILD が使えます。オプションを変更するだけなどの場合、後者が便利になるかもしれません。

PKGBUILD の変数を定義する

PKGBUILD のサンプルは /usr/share/pacman/ にあります。PKGBUILD で利用できる変数は PKGBUILD の記事で説明されています。

パッケージをビルドするために必要な以下の三つの変数は、makepkg によってあらかじめ定義されます:

startdir
PKGBUILD のあるディレクトリへの絶対パスです。$startdir/src$startdir/pkg として $srcdir$pkgdir の代わりに使われていましたが、今ではこれらが一致する保証はありません。この変数を使うことは非推奨です、使うべきでありません。
srcdir
makepkg がソースファイルを展開、またはコピーしてくるディレクトリです。
pkgdir
build() が終わった後、makepkg はここに生成されたファイルをパッケージに入れます。ここがパッケージのルートディレクトリになります。

これらの変数は全て絶対パスなので、適切にこれらの変数を使う限り作業ディレクトリについて心配する必要はありません。

Note: makepkg、そして build()package() 関数は対話式になるようにはなっていません。特にビルドログを有効にして (-l)、これらの関数で対話式のユーティリティやスクリプトを呼び出すと makepkg が破壊される可能性があります (FS#13214 を参照)。
Note: 現在のパッケージメンテナの他に、以前のメンテナが貢献者として記載されることがあります。

PKGBUILD の関数

5つの関数が存在し、全て存在する場合ここに記載している順番どおりに実行されます。関数が存在しないときは、スキップされます。

Note: package() 関数は省略できません、この関数は全ての PKGBUILD で必須になります。

関数 pkgver()

pacman 4.1 から採用され、makepkg の実行中に pkgver 変数を更新することができます。pkgver() はソースが取得・展開されたすぐ後に実行されます。

git/svn/hg などのパッケージを作成するときにこの関数は特に便利です。なぜならビルドプロセスは同じままでも、ソースは毎日・毎時間更新される可能性があるからです。昔は日時を pkgver フィールドに入れていたため、ソフトウェアが更新されていなくても、makepkg はバージョンが変更されたと考えてリビルドをしていました。この関数では git describe, hg identify -ni などのコマンドが有用です。PKGBUILD を投稿する前に、pkgver() 関数がビルドを停止させないかテストしてください。

Note: pkgver には空白やハイフン (-) を含めることができません。sed を使って対処してください。

関数 prepare()

Pacman 4.1 から prepare() 関数が導入されました。この関数では、パッチなどの、ソースをビルドする前の準備に使われるコマンドを実行します。この関数は build 関数の前、パッケージの展開の後に実行されます。展開が省略された場合 (makepkg -e)、prepare() は実行されません。

Note: (man PKGBUILD より) この関数は bash -e モードで実行されるため、コマンドのどれかが0以外のステータスコードで終了したときこの関数は終了します。

関数 build()

さて、PKGBUILD ファイルの中に build() 関数を定義しなくてはなりません。この関数、build()Bash の文法を使って、ソフトウェアを自動的にコンパイルします。そして pkg ディレクトリを作成しここにソフトウェアをインストールします。これによって makepkg はファイルシステムをふるいにかけることなくファイルをパッケージにまとめることができます。

build() 関数はまず展開されたソースコードのディレクトリに入ります。makepkgbuild() を実行する前にカレントディレクトリを srcdir に移動するので、ほとんどの場合最初のコマンドは以下のようになるでしょう:

cd "$pkgname-$pkgver"

/usr/share/pacman/PKGBUILD.proto ファイルでは上のコマンドの代わりに次のコマンドを使うことを提案しています:

cd "$srcdir/$pkgname-$pkgver"

ただし、$srcdir は絶対パスなので違いはありません。

そして、手動でソフトウェアをコンパイルをするのと同じコマンドを書き連ねます。build() 関数は、煎じ詰めて言えば手でコンパイルするのに必要な操作を自動化したものなのです。今パッケージしているソフトウェアが configure を使っているのなら、--prefix=/usr を使うのが良いでしょう。(多くのソフトウェアがファイルをインストールするのに使う) /usr/local ディレクトリは、手動でインストールする場合のみに限って使われるべきです。すべての Arch Linux パッケージは、/usr ディレクトリを使うべきです。/usr/share/pacman/PKGBUILD.proto に書かれているように、次の2行はだいたい以下のようになるでしょう:

./configure --prefix=/usr
make
Note: 何もビルドする必要がないソフトウェアの場合は、build() 関数は使用しないでください。build() 関数は不要ですが、package() 関数は必須です。

関数 check()

ここでは make check などのテストを動作させます。テストの必要のないユーザー(や、時にはテストを通過させるようにパッケージを修正できないメンテナ)は、PKGBUILD やmakepkg で !check オプションを指定することで、これをスキップできます。

関数 package()

最後に、コンパイルされたファイルを、makepkg がファイルを読み込むことができる(そしてパッケージを作成する)ディレクトリに置きます。デフォルトでは pkg ディレクトリです。このディレクトリは単なる fakeroot 環境です。すなわち、このディレクトリはインストール先のファイルシステムの </code>/</code> (root ファイルシステム) に相当します。インストールするファイルは全て pkg 以下に、ディレクトリ構造を保ったまま置かれる必要があります。例えば、ファイルを /usr/bin にインストールさせたい場合は ${pkgdir}/usr/bin にファイルを置きます。数ダースのファイルを手動でコピーしなくてはならない場合はほとんどありません。ほとんどのソフトウェアでは、代わりに make install を呼び出すことでコピーが行われます。ソフトウェアを pkg ディレクトリに正しくインストールするために、最後の行は以下のようになるでしょう:

make DESTDIR="$pkgdir/" install
Note: ときどき MakefileDESTDIR が使われていない場合があります。このときは prefix を使ってください。パッケージのビルドに autoconf/automake が使われているときは、DESTDIR を使ってください。これはマニュアルに文書化されています。もし DESTDIR が使えなければ、make prefix="$pkgdir/usr/" install を試してください。それでもだめなら、"make <...> install" によって実行されるインストールコマンドをもっと調べる必要があります。

稀に、一つのディレクトリの中にすべてのファイルが置かれ、ソフトウェアをそこから実行するようにされていることがあります。こうした場合には、そのディレクトリを $pkgdir/opt にコピーするのが賢明です。

多くの場合では、pkg 下のサブディレクトリはインストールプロセスで自動的に作られます。しかし、そうでない場合は makepkg は大量のエラーを吐いて失敗します。この場合、必要なサブディレクトリを build() 関数内で mkdir -p コマンドを実行することで、インストール作業の前にあらかじめ生成してください。

昔のパッケージでは package() 関数はなく、この操作は build() でまとめて行われていました。PKGBUILDbuild() がない場合は、build() 全体が fakeroot で実行されます。package() が定義されている場合、build()makepkg を実行したユーザで実行され、package() だけが fakeroot で実行されます

また、makepkg --repackagepackage() だけを呼び出します。パッケージの depends 変数をだけ変更したときなどに、ソースを再コンパイルせずパッケージを作成ができ、時間を節約することができます。

Note: package() は PKGBUILD で唯一の必須関数です。プログラムをインストールするのに必要なのがファイルをディレクトリにコピーするだけの場合、build() 関数ではなく package() 関数にコマンドを記述してください。

PKGBUILD とパッケージのテスト

build() 関数を記述している間、バグがないことを確認するために変更をテストしたくなるかもしれません。PKGBUILD ファイルが含まれているディレクトリで makepkg コマンドを実行してすることでテストすることができます。フォーマットが正しい PKGBUILD なら、makepkg はパッケージを作成します。PKGBUILD が壊れていたり未完成だと、エラーを吐きます。

makepkg は問題なく終了すると、作業ディレクトリに pkgname-pkgver.pkg.tar.xz という名前のファイルを作成します。このパッケージは pacman -U コマンドでインストールすることがdけいます。ただし、パッケージファイルが作られたというだけでは完全に機能するとは言えません。あるいはディレクトリだけでファイルが全く含まれていない可能性もあります (例えば、prefix が間違って指定されているとか)。pacman の query 関数を使うことでパッケージに含まれているファイルのリスト、パッケージが必要とする依存パッケージを pacman -Qlp [package file]pacman -Qip [package file] でそれぞれ表示することができます。

パッケージが問題ないようでしたら、これであなたの作業は終了です!ただし、PKGBUILD ファイルを公開するつもりならば、depends の中身を何度もチェックするべきです。

また、パッケージバイナリが完璧に動くことを確認しましょう!全ての必要なファイルが含まれているが、(システムの他の部分と問題を起こすような)度しがたい設定オプションによってクラッシュするパッケージを公開するのは迷惑です。勿論、あなた自身のためだけにパッケージをコンパイルするのなら、品質保証について心配しすぎる必要はありません。誤りによって苦しむのはあなただけなのですから。

パッケージの正常性のテスト

パッケージが機能するかテストした後 namcap を使ってエラーがないか確認してください:

$ namcap PKGBUILD
$ namcap <package file name>.pkg.tar.xz

Namcap は以下を行います:

  1. PKGBUILD の中身を見て、よくある間違いやパッケージファイルの階層に不必要な・間違って置かれたファイルがないか確認します。
  2. ldd を使ってパッケージ内の全ての ELF ファイルをスキャンし、必要な共有ライブラリがあるパッケージが depends に欠けていることや、推移的な依存として省略できるパッケージを自動で報告します。
  3. 欠けている、もしくは不要な依存パッケージのヒューリスティック検索。

などなど。パッケージを namcap でチェックする習慣を実践することでパッケージを投稿した後に単純な間違いを修正する手間が省けます。

AUR にパッケージを送信する

Arch User Repository (日本語)#パッケージを投稿する に、投稿する方法について詳しい説明があります。

要約

  1. パッケージにしたいソフトウェアのソース tarball をダウンロードする。
  2. パッケージのコンパイルを試行し任意のディレクトリにインストールする。
  3. プロトタイプの /usr/share/pacman/PKGBUILD.proto をコピーして PKGBUILD に名前を変更して一時的な作業ディレクトリに置く -- ~/abs/ が推奨。
  4. パッケージの必要に応じて PKGBUILD を編集する。
  5. makepkg を実行して作られたパッケージが正しくビルドされているか確認する。
  6. 正しくビルドされるまで、前の2つの手順を繰り返す。

注意点

  • Before you can automate the package building process, you should have done it manually at least once unless you know exactly what you are doing in advance, in which case you would not be reading this in the first place. Unfortunately, although a good bunch of program authors stick to the 3-step build cycle of "./configure; make; make install", this is not always the case, and things can get real ugly if you have to apply patches to make everything work at all. Rule of thumb: If you cannot get the program to compile from the source tarball, and make it install itself to a defined, temporary subdirectory, you do not even need to try packaging it. There is not any magic pixie dust in makepkg that makes source problems go away.
  • In a few cases, the packages are not even available as source and you have to use something like sh installer.run to get it to work. You will have to do quite a bit of research (read READMEs, INSTALL instructions, man pages, perhaps ebuilds from Gentoo or other package installers, possibly even the MAKEFILEs or source code) to get it working. In some really bad cases, you have to edit the source files to get it to work at all. However, makepkg needs to be completely autonomous, with no user input. Therefore if you need to edit the makefiles, you may have to bundle a custom patch with the PKGBUILD and install it from inside the prepare() function, or you might have to issue some sed commands from inside the prepare() function.

より詳細なガイドライン

Template:Package Guidelines

参照