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

From ArchWiki
Jump to: navigation, search
m (update)
Line 1: Line 1:
[[Category:Development (日本語)]]
+
[[Category:About Arch (日本語)]]
 
[[Category:Package management (日本語)]]
 
[[Category:Package management (日本語)]]
 
[[Category:日本語]]
 
[[Category:日本語]]
Line 5: Line 5:
 
[[en:Creating Packages]]
 
[[en:Creating Packages]]
 
[[es:Creating Packages]]
 
[[es:Creating Packages]]
 +
[[fr:Standard_paquetage]]
 
[[it:Creating Packages]]
 
[[it:Creating Packages]]
 
[[ru:Creating Packages]]
 
[[ru:Creating Packages]]
Line 10: Line 11:
 
[[tr:Paket_oluşturma]]
 
[[tr:Paket_oluşturma]]
 
[[zh-CN:Creating Packages]]
 
[[zh-CN:Creating Packages]]
 +
{{Article summary start|概要}}
 +
{{Article summary text|この記事では [[Arch User Repository (日本語)|AUR]] に投稿するためのパッケージを作成するのに必要な技術的な知識を解説しています。パッケージの質を向上させるためのルール・方法などの説明は [[Arch Packaging Standards (日本語)|Arch Packaging Standards]] を参照してください。}}
 +
{{Article summary heading|関連項目}}
 +
{{Article summary wiki|Arch Build System (日本語)}}
 +
{{Article summary wiki|Arch User Repository (日本語)}}
 +
{{Article summary wiki|makepkg (日本語)}}
 +
{{Article summary wiki|pacman (日本語)}}
 +
{{Article summary wiki|PKGBUILD (日本語)}}
 +
{{Article summary wiki|Patching in ABS}}
 +
{{Article summary end}}
  
{{Message_box
+
この記事は、Arch Linux の ports 風のビルドシステムを使ってパッケージを自作するユーザーの助けになることを目的としています。この記事の扱う範囲は PKGBUILD ({{ic|makepkg}} によって読み込まれるパッケージ定義ファイル) の書き方についてです。すでに PKGBUILD が用意できている場合、[[makepkg (日本語)|makepkg]] の項目を参照してください。
|id              = partial translation
+
|signal          = [[Image:Tango-dialog-warning.png]]
+
|heading        = 翻訳中途
+
|message        = 一部が未翻訳だったり、節が抜け落ちていたりします。}}
+
{{TranslationStatus (日本語)|Creating_Packages|2012-07-15|212288}}
+
  
<!-- This article aims to assist users creating their own packages using the Arch Linux "ports-like" build system. It covers creation of a PKGBUILD – a package build description file sourced by makepkg to create a binary package from source. If already in possession of a PKGBUILD, see makepkg. -->
 
この記事は、Arch Linux の ports 風のビルドシステムを使ってユーザーがパッケージを自作する助けになることを目的としています。この記事の扱う範囲はPKGBUILD(makepkgによって読み込まれるパッケージ定義ファイル)の書き方についてです。すでにPKGBUILDが用意できている場合、[[makepkg]]の項目を参照してください。
 
 
[[Arch Build System]]にはArchLinuxのパッケージを作成、修正するためのツールやファイルについての概要があります。そこには、既存のパッケージをカスタマイズしたり、再コンパイルしたりするのには十分な内容かもしれませんが、新しくパッケージを作成する時は、この記事を読んでください。
 
 
<!-- Overview -->
 
 
==概要==
 
==概要==
<!-- Packages in Arch Linux are built using the makepkg utility and the information stored in a PKGBUILD file. When makepkg is run, it searches for a PKGBUILD in the current directory and follows the instructions therein to either compile or otherwise acquire the required files to be packaged within a package file (pkgname.pkg.tar.xz). The resulting package contains binary files and installation instructions; readily installed with pacman. -->
 
Arch Linux のパッケージは、makepkgユーティリティーとPKGBUILDに記載された情報からビルドされます。makepakgが実行されると、カレントディレクトリのPKGBUILDを見て、ソースをコンパイルするか必要なファイルをダウンロードするかの指示に従います。こうして出来上がったパッケージはバイナリとインストールの実行スクリプトが含まれ、pacmanでインストールできるものになります。
 
  
<!--
+
Arch Linux のパッケージは、[[makepkg (日本語)|makepkg]] ユーティリティーと [[PKGBUILD (日本語)|PKGBUILD]] に記載された情報からビルドされます。{{ic|makepkg}} が実行されると、カレントディレクトリの {{ic|PKGBUILD}} を見て、ソースをコンパイルするか必要なファイルをダウンロードするかの指示に従ってパッケージファイル ({{ic|pkgname.pkg.tar.xz}}) が作成されます。こうして出来上がったパッケージはバイナリとインストールの実行スクリプトが含まれ、[[pacman (日本語)|pacman]] でインストールできるものになります。
An Arch package is no more than a tar archive, or 'tarball', compressed using xz which contains:-->
+
Arch のパッケージは、単に以下のファイルが tar アーカイブ、つまりtarballにまとめられ、xzで圧縮されたものです。
+
<!--    The binary files to install.  
+
  
    .PKGINFO: contains all the metadata needed by pacman to deal with packages, dependencies, etc.
+
Arch のパッケージは、以下のファイルが tar アーカイブ、つまり 'tarball' にまとめられ、xz で圧縮されたものです。
 
+
    .INSTALL: an optional file used to execute commands after the install/upgrade/remove stage. (This file is present only if specified in the PKGBUILD.)
+
 
+
    .Changelog: an optional file kept by the package maintainer documenting the changes of the package. (It is not present in all packages.)  -->
+
  
 
* インストールするバイナリやファイル。
 
* インストールするバイナリやファイル。
* {{ic|.PKGINFO}} pacman でパッケージ管理や依存解決に必要なすべての情報が書かれたファイル。
+
* {{ic|.PKGINFO}}: pacman でパッケージ管理や依存解決をするために必要なすべての情報が書かれたファイル。
* {{ic|.INSTALL}} オプショナルなファイル。インストール/アップグレード/削除の後に実行される。(PKGBUILDで指定された場合のみ存在する)
+
* {{ic|.MTREE}}: ファイルのハッシュとタイムスタンプ。ローカルデータベースに含めることで pacman はパッケージの整合性を検証することができます。
* {{ic|.Changelog}} パッケージメンテナによるパッケージの更新についての覚え書き。(必ず付属するとは限らない)
+
* {{ic|.INSTALL}}: 任意のファイル。インストール/アップグレード/削除の後に実行される ({{ic|PKGBUILD}} で指定された場合のみ存在する)
 +
* {{ic|.Changelog}}: パッケージメンテナによるパッケージの更新についての覚え書き (必ず付属するとは限らない)
  
<!--
 
== Preparation ==
 
===Prerequisite software===
 
-->
 
 
== 準備 ==
 
== 準備 ==
 +
 
=== ソフトウェアの準備 ===
 
=== ソフトウェアの準備 ===
<!-- First ensure that the necessary tools are installed. The package group {{Grp|base-devel}} should be sufficient; it includes '''make''' and additional tools needed for compiling from source.-->
 
  
まず、必要なツールがインストールされているか確認してください。 {{Grp|base-devel}}があれば十分です。'''make'''とその他のコンパイルに必要なツールが含まれています。
+
まず、必要なツールがインストールされているか確認してください。 {{Grp|base-devel}} があれば十分です。このグループには '''make''' などのコンパイルに必要なツールが含まれています。
  
 
  # pacman -S base-devel
 
  # pacman -S base-devel
  
<!-- One of the key tools for building packages is [[makepkg]] (provided by {{Pkg|pacman}}) which does the following: -->
+
{{Pkg|pacman}} で提供される [[makepkg (日本語)|makepkg]] はパッケージ作成で最も重要なツールの一つです。makepkg は以下を行います:
{{Pkg|pacman}}で提供される makepkg はパッケージ作成で最も重要なツールの一つです。makepkgは次のようなことをします。
+
<!--
+
#Checks if package dependencies are installed.
+
#Downloads the source file(s) from the specified server(s).
+
#Unpacks the source file(s).
+
#Compiles the software and installs it under a fakeroot environment.
+
#Strips symbols from binaries and libraries.
+
#Generates the package meta file which is included with each package.
+
#Compresses the fakeroot environment into a package file.
+
#Stores the package file in the configured destination directory, which is the present working directory by default.
+
-->
+
 
+
 
# 依存パッケージがインストールされているかどうか確認する。
 
# 依存パッケージがインストールされているかどうか確認する。
 
# ソースをサーバーからダウンロードする。
 
# ソースをサーバーからダウンロードする。
# 圧縮されたソースファイルを展開する
+
# 圧縮されたソースファイルを展開する。
# fakeroot環境でコンパイルし、インストールする。
+
# fakeroot 環境でコンパイルし、インストールする。
# バイナリやライブラリから不要シンボルを除去する。(symbol stripping)
+
# バイナリやライブラリから不要シンボルを除去する (symbol stripping)
 
# パッケージのメタデータを生成する。
 
# パッケージのメタデータを生成する。
# fakeroot環境をパッケージに圧縮する。
+
# fakeroot 環境をパッケージに圧縮する。
 
# パッケージファイルを出力先ディレクトリに保存する。デフォルトでは作業ディレクトリ。
 
# パッケージファイルを出力先ディレクトリに保存する。デフォルトでは作業ディレクトリ。
<!--
 
=== Download and test the installation ===
 
  
Download the source tarball of the software you want to package, extract it, and follow the author's steps to install the program.  Make a note of all commands and/or steps needed to compile and install it. You will be repeating those same commands in the ''PKGBUILD'' file.
+
=== インストールのダウンロードとテスト ===
  
Most software authors stick to the 3-step build cycle:
+
パッケージにしたいソフトウェアのソース tarball をダウンロードして、展開してください。その後ソフトウェアの作成者の指示に従ってプログラムをインストールしてください。ソフトウェアをコンパイル・インストールするのに必要なコマンド・手順を全て手控えておきましょう。''PKGBUILD'' ファイルの中で同じコマンドを使うことになります。
 +
 
 +
ほとんどのソフトウェアは3ステップでビルドします:
  
 
  ./configure
 
  ./configure
Line 88: Line 64:
 
  make install
 
  make install
  
This is a good time to make sure the program is working correctly.
+
プログラムが正しく動作するか確認すると良いでしょう。
-->
+
<!-- この節は必要なのか? -->
+
 
+
  
<!-- == Creating a PKGBUILD == -->
 
 
== PKGBUILDの作成 ==
 
== PKGBUILDの作成 ==
<!--
 
When you run {{ic|makepkg}}, it will look for a {{ic|PKGBUILD}} file in the present working directory. If a {{ic|PKGBUILD}} file is found it will download the software's source code and compile it according to the instructions specified in the {{ic|PKGBUILD}} file. The instructions must be fully interpretable by the [[Wikipedia:Bash_(Unix_shell)|Bash]] shell. After successful completion, the resulting binaries and metadata of the package, i.e. package version and dependencies, are packed in a {{ic|pkgname.pkg.tar.xz}} package file that can be installed with {{ic|pacman -U ''<package file>''}}.
 
-->
 
  
パッケージ作成に必要な情報は全て<code>PKGBUILD</code>に書かれています。<code>makepkg</code>は実行されると、カレントディレクトリに<code>PKGBUILD</code>ファイルがあるか探し、そこに書かれていることに従ってソフトウェアのソースコードをコンパイルします。PKGBUILDに書かれている指示は、Bashとして実行可能である必要があります。コンパイルが無事終了すれば、出来上がったバイナリと、バージョンや依存パッケージなどのパッケージのメタデータが<code>''パッケージ名''.pkg.tar.gz</code>にまとめられます。このパッケージファイルは<code>pacman -U ''パッケージ名''</code>でインストールすることができます。
+
パッケージ作成に必要な情報は全て <code>PKGBUILD</code> に書かれています。<code>makepkg</code> は実行されると、カレントディレクトリに <code>PKGBUILD</code> ファイルがあるか探し、そこに書かれていることに従ってソフトウェアのソースコードをコンパイルします。{{ic|PKGBUILD}} に書かれている指示は、[[Wikipedia:ja:Bash|Bash]] として実行可能である必要があります。コンパイルが無事終了すれば、出来上がったバイナリと、バージョンや依存パッケージなどのパッケージのメタデータが <code>''パッケージ名''.pkg.tar.xz</code> にまとめられます。このパッケージファイルは <code>pacman -U ''パッケージファイル''</code> でインストールすることができます。
  
<!-- To begin with a new package, you should first create an empty working directory, (preferably {{ic|~/abs/'''pkgname'''}}), change into that directory, and create a {{ic|PKGBUILD}} file.  You can either copy the prototype PKGBUILD {{ic|/usr/share/pacman/PKGBUILD.proto}} to your working directory or copy a {{ic|PKGBUILD}} from a similar package. The latter may be useful if you only need to change a few options. -->
+
新しいパッケージを作るには、まず空の作業ディレクトリを用意します ({{ic|~/abs/''パッケージ名''}} が推奨です)。このディレクトリにファイル {{ic|PKGBUILD}} を作成します。プロトタイプとして、{{ic|/usr/share/pacman/PKGBUILD.proto}} や、類似パッケージの {{ic|PKGBUILD}} が使えます。オプションを変更するだけなどの場合、後者が便利になるかもしれません。
新しいパッケージを作るには、まず空の作業ディレクトリを用意します。({{ic|~/abs/''パッケージ名''}}がおすすめです。) このディレクトリにファイル{{ic|PKGBUILD}}を作成します。プロトタイプとして、{{ic|/usr/share/pacman/PKGBUILD.proto}}や、類似パッケージのPKGBUILDが使えます。
+
  
===PKGBUILDの変数を定義する===
+
===PKGBUILD の変数を定義する===
{{Message_box
+
|id              = section move suggested
+
|signal          = [[Image:Tango-dialog-warning.png]]
+
|heading        = この節は、[[PKGBUILD (日本語)]]に移動する必要があります。
+
|message        = 節が長く、翻訳元では移動されています。}}
+
*'''pkgname''' はこのパッケージの名前です。慣習的に全て小文字です。任意の名前を付けることができますが、作業ディレクトリ、ダウンロードするソースファイル、パッケージ名全ての名前を統一すると便利です。
+
  
*'''pkgver'''はパッケージのバージョンです。アルファベット、数字、ピリオドが使えますが、ハイフンは使え'''ません'''。この変数はパッケージングしようとしているプログラムのバージョンを表しています(メジャーバージョン.マイナーバージョン.バグフィックスもしくはメジャーバージョン.日付など)。'''pkgname'''と同様に、ソースファイルの名前と同じにしておくと後の作業が簡単になり、そして柔軟性を持たせることができます。ソースファイルのバージョン番号にハイフンが使われている場合にはアンダースコアに置換します('0.99-10' => '0.99_10')。
+
PKGBUILD のサンプルは {{Ic|/usr/share/pacman/}} にあります。{{ic|PKGBUILD}} で利用できる変数は [[PKGBUILD (日本語)|PKGBUILD]] の記事で説明されています。
  
*'''pkgrel'''はパッケージのリリース番号です。1から始め、あなたがこのパッケージをリリースする度に1ずつ増やしてください。この変数は同じバージョンのソースから別の新しいパッケージを作成するとき、違いを明示するために使います。上流が新しいバージョンのソースをリリースしたら、<code>pkgrel</code>は1に戻ります。
+
パッケージをビルドするために必要な以下の三つの変数は、''makepkg'' によってあらかじめ定義されます:
 +
; {{ic|startdir}}: {{ic|PKGBUILD}} のあるディレクトリへの絶対パスです。{{ic|$startdir/src}} や {{ic|$startdir/pkg}} として {{ic|$srcdir}} や {{ic|$pkgdir}} の代わりに使われていましたが、今ではこれらが一致する保証はありません。この変数を使うことは非推奨です、使うべきでありません。
 +
; {{ic|srcdir}}: {{ic|makepkg}} がソースファイルを展開、またはコピーしてくるディレクトリです。
 +
; {{ic|pkgdir}}: build() が終わった後、{{ic|makepkg}} はここに生成されたファイルをパッケージに入れます。ここがパッケージのルートディレクトリになります。
 +
これらの変数は全て''絶対''パスなので、適切にこれらの変数を使う限り作業ディレクトリについて心配する必要はありません。
  
*'''pkgdesc'''には短かい(通常76文字未満の)、パッケージの説明を記述します。通常、ここで改めてプログラムの名前を書く必要はありません。つまり、<code>'''xgl is''' OpenGL accelarated X server</code>ではなく、<code>OpenGL accelarated ...</code>と書く方が良いということです。
+
{{Note|''makepkg''、そして {{ic|build()}} と {{ic|package()}} 関数は対話式になるようにはなっていません。特にビルドログを有効にして ({{ic|-l}})、これらの関数で対話式のユーティリティやスクリプトを呼び出すと ''makepkg'' が破壊される可能性があります ({{Bug|13214}} を参照)。}}
  
*'''arch'''はPKGBUILDが対象とするアーキテクチャ名の配列です。現在のところ、'i686' または 'x86_64' から指定してください。'any' を指定するとアーキテクチャに関わらずに動くということになります。パッケージ作成中には<code>$CARCH</code>で、選ばれたアーキテクチャが何であるかアクセスすることができます。
+
{{Note|現在のパッケージメンテナの他に、以前のメンテナが貢献者として記載されることがあります。}}
  
*'''url'''には更なる情報を求める利用者の助けになるよう、このプログラムのオフィシャルサイトのアドレスを設定します。
+
=== PKGBUILD の関数 ===
  
*'''license'''にはライセンスの種類を記述します。もし分からない場合は'unknown'としてください。/usr/share/locenses/common/以下にあるライセンス名を使って下さい。(GPLやCCPLなど)
+
5つの関数が存在し、全て存在する場合ここに記載している順番どおりに実行されます。関数が存在しないときは、スキップされます。
  
* ''''groups''''にはパッケージが所属するグループを記述します。例えば''kdebase''パッケージをインストールする場合、''kde''グループに所属する全てのパッケージをインストールすることになります。
+
{{Note|{{ic|package()}} 関数は省略できません、この関数は全ての PKGBUILD で必須になります。}}
  
*'''depends'''にはこのプログラムが実行される前にインストールされる必要のあるパッケージ名を配列で(スペースによる区切りで)記述します。パッケージ名はシングルクォートで囲むことができます。配列は丸括弧で囲みます。プログラムによっては、特定のバージョンに依存していることがありますが、その場合はシングルクォート内で数学の不等号記号を使うことができます。例えば、glibcパッケージと1.8.0以上のバージョンのslangパッケージに依存している場合、'''<code>depends=('glibc' 'slang>=1.8.0')</code>'''と記述します。
+
==== 関数 {{ic|pkgver()}} ====
  
*'''makedepends'''には、パッケージ作成時にのみ必要で*インストール後には不要な*パッケージ名の配列を記述します。 例えば、パッチを解凍するときに必要な<code>unarj</code>などを記述します。
+
pacman 4.1 から採用され、makepkg の実行中に pkgver 変数を更新することができます。{{ic|pkgver()}} はソースが取得・展開されたすぐ後に実行されます。
  
*'''optdepends'''には、このパッケージの動作に不可欠ではないけれども、インストールすると機能が追加されるパッケージを記述します。現在、pacmanはこの情報を利用者に通知する目的でしか使用しません(```depends```と異なり、依存性の解決には使われません)。書式は次のようにします: '''<code>optdepends=('fakeroot: for makepkg usage as normal user')</code>'''
+
[[VCS PKGBUILD Guidelines|git/svn/hg などのパッケージを作成する]]ときにこの関数は特に便利です。なぜならビルドプロセスは同じままでも、ソースは毎日・毎時間更新される可能性があるからです。昔は日時を pkgver フィールドに入れていたため、ソフトウェアが更新されていなくても、makepkg はバージョンが変更されたと考えてリビルドをしていました。この関数では {{ic|git describe}}, {{ic|hg identify -ni}} などのコマンドが有用です。PKGBUILD を投稿する前に、{{ic|pkgver()}} 関数がビルドを停止させないかテストしてください。
 +
{{Note|pkgver には空白やハイフン ({{ic|-}}) を含めることができません。sed を使って対処してください。}}
  
*'''provides'''には、このパッケージが提供するパッケージ名、あるいは'sh'や'cron'などの仮想的なパッケージ名を配列で記述します。この変数を使うとき、バージョンに依存した問題がある場合にはバージョン情報(pkgverやpkgrel)も記述しなければなりません。
+
==== 関数 {{ic|prepare()}} ====
'''''NOTE:'''''pacman 3.1.0はこの機能に少々問題があり、3.1.1で修正される予定です。このドキュメントでは3.1.1の文法を参照しています(訳注:2009年4月20日時点でのpacmanのバージョンは3.2.2です) '''例1:''' もし、qt 3.3.8相当の機能を提供する自作パッケージqt-fooを作成した場合、'''<code>provides=('qt=3.3.8')</code>'''と記述します。'''<code>provides=('qt')</code>'''だけでは特定のバージョンのqtを必要とする依存関係を解決することができません。<br/>'''例2:''' パッケージperl-5.10.0がperlのモジュールであるperl-foo 5.2.1とperl-bar 2.5も提供する場合、'''<code>provides=('perl-foo=5.2.1' 'perl-bar=2.5')</code>'''と記述します。
+
  
*'''conflicts'''には、一緒にインストールすると問題を起こすパッケージ名を配列で記述します。dependsと同様にバージョンの情報を指定することができます。
+
Pacman 4.1 から {{ic|prepare()}} 関数が導入されました。この関数では、パッチなどの、ソースをビルドする前の準備に使われるコマンドを実行します。この関数は build 関数の前、パッケージの展開の後に実行されます。展開が省略された場合 ({{ic|makepkg -e}})、{{ic|prepare()}} は実行されません。
  
*'''replaces'''にはこのパッケージによって置き換えられる古いパッケージを配列で記述します。
+
{{Note| ({{ic|man PKGBUILD}} より) この関数は {{ic|bash -e}} モードで実行されるため、コマンドのどれかが0以外のステータスコードで終了したときこの関数は終了します。}}
  
* '''''backup'''''
+
====関数 {{ic|build()}} ====
** このパッケージが削除されるとき''file.pacsave''という名前でバックアップされるファイルを配列で記述します。''/etc''以下の設定ファイルをインストールするパッケージで広く使われています。
+
  
* '''''options'''''
+
さて、{{ic|PKGBUILD}} ファイルの中に {{ic|build()}} 関数を定義しなくてはなりません。この関数、<code>build()</code> は [[Wikipedia:ja:Bash|Bash]] の文法を使って、ソフトウェアを自動的にコンパイルします。そして {{ic|pkg}} ディレクトリを作成しここにソフトウェアをインストールします。これによって ''makepkg'' はファイルシステムをふるいにかけることなくファイルをパッケージにまとめることができます。
** この変数は''makepkg''のデフォルトの振る舞いを上書きします。設定したいオプションを配列で指定します。デフォルトのオプションを無効にするには頭に'''!'''を付けます。以下のオプションが指定できます。
+
*** '''''strip''''' - バイナリとライブラリからシンボルを除去します
+
*** '''''docs''''' - ''/docs''ディレクトリを残します
+
*** '''''libtool''''' - ''libtool''ファイル(.la)をパッケージに残します
+
*** '''''emptydirs''''' - 空ディレクトリをパッケージに残します
+
*** '''''zipman''''' - ''man''、''info''ページを''gzip''で圧縮します
+
*** '''''ccache''''' - ビルド中に''ccache''を使うことを許可します。否定形の''!ccache''は、''ccache''を使ったビルドに問題がある場合に便利です。
+
*** '''''distcc''''' - ビルド中に''distcc''を使うことを許可します。否定形の''!distcc''は、''distcc''を使ったビルドに問題がある場合に便利です。
+
*** '''''makeflags''''' - ビルド中に利用者が指定する''makeflags''を使うことを許可します。否定形の''!makeflags''は、''makeflags''を使ったビルドに問題がある場合に便利です。
+
*** '''''force''''' -  アップグレードする必要のないバージョンであっても強制的に''pacman''によるアップグレードを行うようにします。バージョン番号の付け方を変更する場合(あるいはアルファベットでのバージョン管理)に便利です。
+
  
* '''''install'''''
+
{{ic|build()}} 関数はまず展開されたソースコードのディレクトリに入ります。''makepkg'' は {{ic|build()}} を実行する前にカレントディレクトリを {{ic|srcdir}} に移動するので、ほとんどの場合最初のコマンドは以下のようになるでしょう:
** ''.install''スクリプトをパッケージに含めることができるようになります。''pacman''はパッケージのインストール、削除、アップグレード時に実行されるスクリプトをパッケージに含めることができます。
+
  
*'''source:''' パッケージ作成に必要なファイルを配列にして記述します。大抵のパッケージではHTTP/FTPのURLがダブルクォーテーションで囲まれて記述されます。<code>PKGBUILD</code>の雛型にはここまでに設定した変数がパッケージ名やバージョンを効果的に記述する方法が書いてあります。もしダウンロードできないファイルを供給する必要がある時(例えば自作のパッチ等)、<code>PKGBUILD</code>と同じディレクトリにそのファイルを置き、'''sources'''にファイル名を追加します。追加したパスは全て<code>PKGBUILD</code>からの相対パスとして扱われます。実際のビルドプロセスが始まる前に、ここに記述したファイルはダウンロードされるか存在をチェックされます。もしファイルが見つからない場合、<code>makepkg</code>は実行されませ ん。
+
  cd "$pkgname-$pkgver"
  
* '''''noextract'''''
+
{{ic|/usr/share/pacman/PKGBUILD.proto}} ファイルでは上のコマンドの代わりに次のコマンドを使うことを提案しています:
** ''source''にリストされたファイルのうち、''makepkg''によって展開されないものを配列で記述します。これは''bsdtar''で扱えないzipファイルなどに適用されます(訳者不理解:''libarchive''は''unzip''が行うようなランダムアクセスではなく、全てのファイルをストリームとして扱うので''bsdtar''で処理できない?)。このような場合は''makedepends''変数に''unzip''を追加し、以下の行を''build()''の最初に記述します:
+
cd $srcdir/$pkgname-$pkgver
+
unzip [source].zip
+
  
*'''md5sums'''にはソースファイルのmd5チェックサムを配列で記述します。ソースファイルが全て利用可能な状態にあれば、それぞれのファイルに対するmd5ハッシュが自動的に生成され、結果がこの変数と比較されます。'''配列の並びはsourcesの並びと同じである必要があります。'''ソースファイルの順番が問題になることはありませんが、<code>makepkg</code>はどのmd5sumがどのソースファイルから生成されたかを推定せず、以前のダウンロードエラーや操作によって失敗している場合でも喜んでエラーを吐き出すので、'''md5sums'''の順番は重要です(訳者不理解な一文)。'''source'''をちゃんとセットした後に<code>PKGBUILD</code>のあるディレクトリで<code>makepkg -g</code>とすると、自動的に'''md5sums'''を出力してくれます。<code>makepkg -g >>PKGBUILD</code>とするとmd5sumを計算し、<code>PKGBUILD</code>の末尾に記述されるので、適切な行に移動させて下さい。
+
cd "$srcdir/$pkgname-$pkgver"
  
ここまで、パッケージのメタ情報(どこからソースを入手するか、名前は何か等など)を記述してきました。次のステップでは、パッケージングしようとしているプログラムをどのように''コンパイル&インストール''するのか、その方法を説明します。
+
ただし、{{ic|$srcdir}} は絶対パスなので違いはありません。
  
===定義済み変数===
+
そして、手動でソフトウェアをコンパイルをするのと同じコマンドを書き連ねます。{{ic|build()}} 関数は、煎じ詰めて言えば手でコンパイルするのに必要な操作を自動化したものなのです。今パッケージしているソフトウェアが configure を使っているのなら、{{ic|1=--prefix=/usr}} を使うのが良いでしょう。(多くのソフトウェアがファイルをインストールするのに使う) {{ic|/usr/local}} ディレクトリは、手動でインストールする場合のみに限って使われるべきです。すべての Arch Linux パッケージは、{{ic|/usr}} ディレクトリを使うべきです。{{ic|/usr/share/pacman/PKGBUILD.proto}} に書かれているように、次の2行はだいたい以下のようになるでしょう:
<!-- makepkg defines three variables that you should use as part of the build and install process: -->
+
パッケージをビルドするために必要な以下の三つの変数は、makepkgによってあらかじめ定義されます。
+
; {{ic|startdir}} <!--
+
: This contains the absolute path to the directory where the PKGBUILD file is located. This variable used to be used in combination with /src or /pkg postfixes, but the use of srcdir and pkgdir variables is the modern method. $startdir/src is not guaranteed to be the same as $srcdir, and likewise for $pkgdir. Use of this variable is deprecated and strongly discouraged. -->
+
: PKGBUILDのあるディレクトリへの絶対パスです。$startdir/srcや$startdir/pkgとして$srcdirや$pkgdirの代わりに使われていましたが、今ではこれらが一致する保証はありません。'''この変数を使うことは非推奨です。 使うべきでありません。'''
+
; {{ic|srcdir}} <!--
+
: This points to the directory where makepkg extracts or copies all source files. -->
+
: {{ic|makepkg}}がソースファイルを展開、またはコピーしてくるディレクトリです。
+
; {{ic|pkgdir}} <!--
+
: This points to the directory where makepkg bundles the installed package, which becomes the root directory of your built package. -->
+
: build()が終わった後、{{ic|makepkg}}はここに生成されたファイルをパッケージに入れます。ここがパッケージのルートディレクトリになります。
+
  
ソースのtarballをダウンロードし、展開、そして必要なコマンド全てを記述してきました。<code>PKGBUILD</code>の関数<code>build()</code>の中では、これらの操作の実際と、コンパイルが終わったときに全てをパックするための一工夫を行います。
+
./configure --prefix=/usr
 +
make
  
===関数 build()===
+
{{Note|何もビルドする必要がないソフトウェアの場合は、{{ic|build()}} 関数は使用しないでください。{{ic|build()}} 関数は不要ですが、{{ic|package()}} 関数は必須です。}}
<!--
+
Now you need to implement the build() function in the PKGBUILD file. This function uses common shell commands in Bash syntax to automatically compile software and create a pkg directory to install the software to. This allows makepkg to package files without having to sift through your filesystem.
+
-->
+
  
さて、PKGBUILDファイルの中にbuild() 関数を定義しなくてはなりません。この関数は、<code>build()</code>はbashの文法で書かれたスクリプトで、ソフトウェアを自動的にコンパイルします。
+
=== 関数 {{ic|check()}} ===
<!--
+
install云々はpackage()に移行したようなので、省略。
+
-->
+
  
<!--
+
ここでは {{Ic|make check}} などのテストを動作させます。テストの必要のないユーザー(や、時にはテストを通過させるようにパッケージを修正できないメンテナ)は、PKGBUILD やmakepkg で {{Ic|!check}} オプションを指定することで、これをスキップできます。
The first step in the build() function is to change into the directory created by uncompressing the source tarball. In most common cases the first command will look like this:
+
-->
+
build() 関数はまず展開されたソースコードのディレクトリに入ります。コマンドは以下のようになるでしょう。(ただし、$pkgverのアンダースコアをハイフンに変換するコマンドが必要になるかもしれません)
+
  
cd "$srcdir/$pkgname-$pkgver"
+
=== 関数 {{ic|package()}} ===
  
<!--
+
最後に、コンパイルされたファイルを、''makepkg'' がファイルを読み込むことができる(そしてパッケージを作成する)ディレクトリに置きます。デフォルトでは {{ic|pkg}} ディレクトリです。このディレクトリは単なる fakeroot 環境です。すなわち、このディレクトリはインストール先のファイルシステムの </code>/</code> (root ファイルシステム) に相当します。インストールするファイルは全て {{ic|pkg}} 以下に、ディレクトリ構造を保ったまま置かれる必要があります。例えば、ファイルを <code>/usr/bin</code> にインストールさせたい場合は <code>${pkgdir}/usr/bin</code> にファイルを置きます。数ダースのファイルを手動でコピーしなくてはならない場合はほとんどありません。ほとんどのソフトウェアでは、代わりに {{ic|make install}} を呼び出すことでコピーが行われます。ソフトウェアを {{ic|pkg}} ディレクトリに正しくインストールするために、最後の行は以下のようになるでしょう:
Now, you need to list the same commands you used when you manually compiled the software. The build() function in essence automates everything you did by hand and compiles the software in the fakeroot build environment. If the software you are packaging uses a configure script, it is good practice to use --prefix=/usr when building packages for pacman. A lot of software installs files relative to the /usr/local directory, which should only be done if you are manually building from source. All Arch Linux packages should use the /usr directory. As seen in the /usr/share/pacman/PKGBUILD.proto file, the next two lines often look like this:
+
-->
+
そして、手動でソフトウェアをコンパイルをするのと同じコマンドを書き連ねます。build()関数は、煎じ詰めて言えば手でコンパイルするのに必要な操作を自動化したものなのです。<!-- fakeroot環境うんぬんについてはpackage()を参照。-->今パッケージしているソフトウェアがconfigureを使っているのなら、{{ic|--prefix&#61;/usr}}を使うのが良いです。/usr/local ディレクトリは、手動でインストールする場合のみに限って使われるべきです。すべてのArch Linuxパッケージは、/usr ディレクトリを使うべきです。/usr/share/pacman/PKGBUILD.protoに見えるように、次の2行はだいたい以下のようになるでしょう。
+
  
  ./configure --prefix=/usr
+
  make DESTDIR="$pkgdir/" install
make
+
  
<!-- ===The check() function=== -->
+
{{Note|ときどき {{ic|Makefile}} で {{ic|DESTDIR}} が使われていない場合があります。このときは {{ic|prefix}} を使ってください。パッケージのビルドに ''autoconf''/''automake'' が使われているときは、{{ic|DESTDIR}} を使ってください。これはマニュアルに[https://www.gnu.org/software/automake/manual/automake.html#Install 文書化]されています。もし {{ic|DESTDIR}} が使えなければ、{{ic|1=make prefix="$pkgdir/usr/" install}} を試してください。それでもだめなら、"{{ic|make <...> install}}" によって実行されるインストールコマンドをもっと調べる必要があります。}}
=== 関数 check () ===
+
<!-- Place for calls to make check and similar testing routines. Users who don't need it (and occasionally maintainers who can not fix a package for this to pass) can disable it using !check in PKGBUILD/makepkg options. -->
+
ここでは{{ic|make check}}などのテストを動作させます。テストの必要のないユーザー(や、時にはテストを通過させるようにパッケージを修正できないメンテナ)は、PKGBUILDやmakepkgで !check オプションを指定することで、これをスキップできます。
+
  
<!-- === The package() function === -->
+
稀に、一つのディレクトリの中にすべてのファイルが置かれ、ソフトウェアをそこから実行するようにされていることがあります。こうした場合には、そのディレクトリを {{ic|$pkgdir/opt}} にコピーするのが賢明です。
=== 関数 package() ===
+
<!-- The final step is to put the compiled files in a directory where makepkg can retrieve them to create a package. This by default is the pkg directory — a simple fakeroot environment. The pkg directory replicates the hierarchy of the root file system of the software's installation paths. If you have to manually place files under the root of your filesystem, you should install them in the pkg directory under the same directory structure. For example, if you want to install a file to /usr/bin, it should instead be placed under $pkgdir/usr/bin. Very few install procedures require the user to copy dozens of files manually. Instead, for most software, calling make install will do so. The final line should look like the following in order to correctly install the software in the pkg directory:-->
+
最後に、コンパイルされたファイルをmakepkgが読み込み、パッケージを作成するディレクトリ($pkgdir)に置きます。このディレクトリは単なるfake root環境です。すなわち、このディレクトリはインストール先のファイルシステムの</code>/</code>に相当します。インストールするファイルは全て<code>pkg</code>以下に、ディレクトリ構造を保ったまま置かれる必要があります(例えば、<code>myprog</code>を<code>/usr/bin</code>にインストールさせたい場合は<code>${pkgdir}/usr/bin</code>に<code>myprog</code>を置きます)。
+
  
make DESTDIR="$pkgdir" install
+
多くの場合では、{{ic|pkg}} 下のサブディレクトリはインストールプロセスで自動的に作られます。しかし、そうでない場合は ''makepkg'' は大量のエラーを吐いて失敗します。この場合、必要なサブディレクトリを {{ic|build()}} 関数内で {{ic|mkdir -p}} コマンドを実行することで、インストール作業の前にあらかじめ生成してください。
  
<!--
+
昔のパッケージでは {{ic|package()}} 関数はなく、この操作は {{ic|build()}} でまとめて行われていました。{{ic|PKGBUILD}} に {{ic|build()}} がない場合は、{{ic|build()}} 全体が ''fakeroot'' で実行されます。{{ic|package()}} が定義されている場合、{{ic|build()}} は {{ic|makepkg}} を実行したユーザで実行され、{{ic|package()}} だけが ''fakeroot'' で実行されます
Note: It is sometimes the case where DESTDIR is not used in the Makefile; you may need to use prefix instead. If the package is built with autoconf/automake, use DESTDIR; this is what is documented in the manuals. If DESTDIR does not work, try building with make prefix="$pkgdir/usr/" install. If that does not work, you will have to look further into the install commands that are executed by "make <...> install".
+
-->
+
ときどきMakefileでDESTDIRが使われていない場合があります。このときはprefixを使ってください。autoconf/automakeを使ってパッケージがビルドされているときは、DESTDIRを使ってください。これはマニュアルに文書化されていることです。もし、DESTDIRが使えなければ、make prefix="$pkgdir/usr" installを試してください。それでもだめなら、make ... installによって実行されるインストールコマンドをもっと調べる必要があります。
+
  
<!--
+
また、{{ic|makepkg --repackage}} は {{ic|package()}} だけを呼び出します。パッケージの {{ic|depends}} 変数をだけ変更したときなどに、ソースを再コンパイルせずパッケージを作成ができ、時間を節約することができます。
In some odd cases, the software expects to be run from a single directory. In such cases, it is wise to simply copy these to $pkgdir/opt.
+
-->
+
妙な場合では、ソフトウェアは一つのディレクトリの中にすべてのファイルが置かれ、そこで実行されるように作られています。こうした場合には、そのディレクトリを{{ic|$pkgdir/opt}}にコピーするのが賢明です。
+
  
<!--
+
{{Note|{{ic|package()}} は PKGBUILD で唯一の必須関数です。プログラムをインストールするのに必要なのがファイルをディレクトリにコピーするだけの場合、{{ic|build()}} 関数ではなく {{ic|package()}} 関数にコマンドを記述してください。}}
More often than not, the installation process of the software will create any sub-directories below the pkg directory. If it does not, however, makepkg will generate a lot of errors and you will need to manually create sub-directories by adding the appropriate mkdir -p commands in the build() function before the installation procedure is run.
+
-->
+
多くの場合では、pkg以下のサブディレクトリはインストールプロセスで自動的に作られます。しかし、そうでない場合はmakepkgはエラーを吐いて失敗します。このときは必要なサブディレクトリをbuild()関数で<!--これ本当?--> mkdir -p を実行することで、あらかじめ生成してください。
+
  
<!--
+
== PKGBUILD とパッケージのテスト ==
In old packages, there was no package() function. So, putting compiled files was done at the end of the build() function. If package() is not present, build() runs via fakeroot. If package() is present, build() runs as the user calling makepkg, package() runs via fakeroot.
+
-->
+
昔のパッケージには package() 関数はなく、この操作はbuild()でまとめて行われていました。PKGBUILDにpackage()がない場合は、build()全体がfakerootで実行されます。package()が定義されている場合、build()はmakepkgを実行したユーザで実行され、pacakge()だけがfakerootで実行されます
+
  
<!--
 
makepkg --repackage runs only the package() function, so it creates a *.pkg.* file without compiling the package. This may save time e.g. if you just have changed the depends variable of the package.
 
-->
 
また、{{ic|makepkg --repackage}} は package() だけを呼び出します。 依存パッケージを変更したときなどに、ソースを再コンパイルせずパッケージを作成し、時間を節約するために有効です。
 
 
<!--
 
== Testing the PKGBUILD and package ==
 
-->
 
== 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.
 
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.
  
Line 257: Line 158:
 
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.
 
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.
  
<!--
 
=== Checking package sanity ===
 
-->
 
 
===パッケージの正常性のテスト===
 
===パッケージの正常性のテスト===
  
After testing package functionality check it for errors using [[namcap]]:
+
パッケージが機能するかテストした後 [[namcap]] を使ってエラーがないか確認してください:
 
  $ namcap PKGBUILD
 
  $ namcap PKGBUILD
 
  $ namcap ''<package file name>''.pkg.tar.xz
 
  $ namcap ''<package file name>''.pkg.tar.xz
  
Namcap will:
+
Namcap は以下を行います:
# Check PKGBUILD contents for common errors and package file hierarchy for unnecessary/misplaced files
+
# PKGBUILD の中身を見て、よくある間違いやパッケージファイルの階層に不必要な・間違って置かれたファイルがないか確認します。
# Scan all ELF files in package using {{ic|ldd}}, automatically reporting which packages with required shared libraries are missing from {{Ic|depends}} and which can be omitted as transitive dependencies
+
# {{ic|ldd}} を使ってパッケージ内の全ての ELF ファイルをスキャンし、必要な共有ライブラリがあるパッケージが {{Ic|depends}} に欠けていることや、推移的な依存として省略できるパッケージを自動で報告します。
# Heuristically search for missing and redundant dependencies
+
# 欠けている、もしくは不要な依存パッケージのヒューリスティック検索。
and much more.
+
などなど。パッケージを namcap でチェックする習慣を実践することでパッケージを投稿した後に単純な間違いを修正する手間が省けます。
Get into the habit of checking your packages with namcap to avoid having to fix the simplest mistakes after package submission.
+
  
<!--
+
== AUR にパッケージを送信する ==
==Submitting packages to the AUR==
+
 
-->
+
[[Arch User Repository (日本語)#パッケージを投稿する]] に、投稿する方法について詳しい説明があります。
== AURに送信する ==
+
[[AUR User Guidelines#Submitting packages]]に、送信のプロセスについての詳しい説明があります。
+
  
<!--
 
== Summery ==
 
-->
 
 
== 要約 ==
 
== 要約 ==
#Download the source tarball of the software you want to package.
+
 
#Try compiling the package and installing it into an arbitrary directory.
+
#パッケージにしたいソフトウェアのソース tarball をダウンロードする。
#Copy over the prototype {{ic|/usr/share/pacman/PKGBUILD.proto}} and rename it to {{ic|PKGBUILD}} in a temporary working directory -- preferably {{ic|~/abs/}}.
+
#パッケージのコンパイルを試行し任意のディレクトリにインストールする。
#Edit the {{ic|PKGBUILD}} according to the needs of your package.
+
#プロトタイプの {{ic|/usr/share/pacman/PKGBUILD.proto}} をコピーして {{ic|PKGBUILD}} に名前を変更して一時的な作業ディレクトリに置く -- {{ic|~/abs/}} が推奨。
#Run {{ic|makepkg}} and see whether the resulting package is built correctly.
+
#パッケージの必要に応じて {{ic|PKGBUILD}} を編集する。
#If not, repeat the last two steps.
+
#{{ic|makepkg}} を実行して作られたパッケージが正しくビルドされているか確認する。
<!--
+
#正しくビルドされるまで、前の2つの手順を繰り返す。
=== Warnings ===
+
 
-->
+
 
=== 注意点 ===
 
=== 注意点 ===
 +
 
* 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 "{{ic|./configure}}; {{ic|make}}; {{ic|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 {{ic|makepkg}} that makes source problems go away.
 
* 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 "{{ic|./configure}}; {{ic|make}}; {{ic|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 {{ic|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 {{ic|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, {{ic|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 {{ic|PKGBUILD}} and install it from inside the {{ic|build()}} function, or you might have to issue some {{ic|sed}} commands from inside the {{ic|build()}} function.
+
* In a few cases, the packages are not even available as source and you have to use something like {{ic|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, {{ic|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 {{ic|PKGBUILD}} and install it from inside the {{ic|prepare()}} function, or you might have to issue some {{ic|sed}} commands from inside the {{ic|prepare()}} function.
 +
 
 +
== より詳細なガイドライン ==
 +
{{Package Guidelines}}
  
<!-- ==See Also== -->
 
 
==参照==
 
==参照==
<!--
+
* [https://bbs.archlinux.org/viewtopic.php?id=91408 How to correctly create a patch file]
* [https://bbs.archlinux.org/viewtopic.php?id=91408 How to correctly create a patch file].
+
-->
+
* [https://bbs.archlinux.org/viewtopic.php?id=91408 Arch Linux BBS - How to correctly create a patch file (パッチを書くには)]
+

Revision as of 14:59, 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 とパッケージのテスト

As you are writing the build() function, you will want to test your changes frequently to ensure there are no bugs. You can do this using the makepkg command in the directory containing the PKGBUILD file. With a properly formatted PKGBUILD, makepkg will create a package; with a broken or unfinished PKGBUILD, it will raise an error.

If makepkg finishes successfully, it will place a file named pkgname-pkgver.pkg.tar.xz in your working directory. This package can be installed with the 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 pacman -Qlp [package file] and pacman -Qip [package file] respectively.

If the package looks sane, then you are done! However, if you plan on releasing the PKGBUILD file, it is imperative that you check and double-check the contents of the depends array.

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.

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

パッケージが機能するかテストした後 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

参照