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

From ArchWiki
Jump to: navigation, search
(rm temporary i18n template)
m (updated link)
Line 13: Line 13:
 
{{Bad translation}}
 
{{Bad translation}}
  
[[Arch Build System|ABS - The Arch Build System]]にはArchLinuxのパッケージを作成、修正するためのツールやファイルについての優れた概要があります。もしかしたら、既存のパッケージをカスタマイズ、再コンパイルするだけなら十分な文書かもしれません。しかしながら、新しくパッケージを作成する場合には、他にも知っておくべきガイドラインがあります。この文書はABSについて理解している人を想定しています。
+
[[Arch Build System]]にはArchLinuxのパッケージを作成、修正するためのツールやファイルについての優れた概要があります。もしかしたら、既存のパッケージをカスタマイズ、再コンパイルするだけなら十分な文書かもしれません。しかしながら、新しくパッケージを作成する場合には、他にも知っておくべきガイドラインがあります。この文書はABSについて理解している人を想定しています。
  
 
==ファイルの用意==
 
==ファイルの用意==
Line 209: Line 209:
  
 
==Useful links==
 
==Useful links==
* [[ABS_-_The_Arch_Build_System | ABS - The Arch Build System]]
+
* [[Arch Build System]]
 
* [http://www.archlinux.org/pacman/makepkg.8.html makepkg man page]
 
* [http://www.archlinux.org/pacman/makepkg.8.html makepkg man page]
 
* [[Makepkg|makepkg tutorial]]
 
* [[Makepkg|makepkg tutorial]]

Revision as of 02:36, 17 June 2012

zh-CN:Creating Packages

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: please use the first argument of the template to provide a brief explanation. (Discuss in Talk:Creating Packages (日本語)#)

Tango-preferences-desktop-locale-modified.pngThe translation of this article or section does not reflect the original text.Tango-preferences-desktop-locale-modified.png

Reason: please use the first argument of the template to provide a brief explanation. (Discuss in Talk:Creating Packages (日本語)#)

Arch Build SystemにはArchLinuxのパッケージを作成、修正するためのツールやファイルについての優れた概要があります。もしかしたら、既存のパッケージをカスタマイズ、再コンパイルするだけなら十分な文書かもしれません。しかしながら、新しくパッケージを作成する場合には、他にも知っておくべきガイドラインがあります。この文書はABSについて理解している人を想定しています。

ファイルの用意

パッケージ作成に必要な情報は全てPKGBUILDに書かれています。makepkgは実行されると、カレントディレクトリにPKGBUILDファイルがあるか探し、そこに書かれていることに従ってソフトウェアのソースコードをコンパイルします。コンパイルが正常に終了した後、作成されたバイナリやバージョン、依存性などのメタ情報は全てパッケージ名.pkg.tar.gzに格納されます。このパッケージファイルはpacman -Up パッケージ名でインストールすることができます。

PKGBUILDファイルはパッケージ作成のための全ての情報が、bashで直接解釈できるフォーマットで書かれています(この一文にピンとこなくても心配する必要はありません)。ここで使われる変数は ABSで説明されていますが、重要なもの、混乱しがちなもののほとんどはこの記事でも説明があります。パッケージの作成を始めるにあたり、まずは空の作業ディレクトリを/var/abs/local/<パッケージ名>下に作ると良いでしょう。このディレクトリはABSツリーに組み込まれますが、ツリーをcvsupで同期させても変更されることはありません。作業ディレクトリ下に移動し、PKGBUILDを作成するか、/usr/share/pacman/PKGBUILD.protoもしくは他のパッケージからPKGBUILDをコピーしてきます。後者のやり方は既存のパッケージのコンパイルオプションを編集したいときに便利です。

However you do it, you need a PKGBUILD file to work with here.

変数の編集

PKGBUILDを開き、作成しようとしているパッケージに必要な以下の変数を設定します。

  • pkgname にはこのパッケージの名前を付けます。パッケージ名には慣習として全て小文字を使います。任意の名前を付けることができますが、作業ディレクトリ、ダウンロードするソースファイル、パッケージ名全てに同じ名前を付けると便利です。
  • pkgverにはパッケージのバージョンを付けます。アルファベット、数字、ピリオドを含めることができますが、ハイフンを含めることはできません。この変数はパッケージングしようとしているプログラムのバージョンを表しています(メジャーバージョン.マイナーバージョン.バグフィックスもしくはメジャーバージョン.日付など)。pkgnameと同様に、ソースファイルの名前と同じにしておくと後の作業が簡単になり、そして柔軟性を持たせることができます。ソースファイルのバージョン付けにハイフンが使われている場合にはアンダースコアに置換します('0.99-10' => '0.99_10')。
  • pkgrelにはパッケージのリリース番号を入れてください。1から始め、あなたがこのパッケージをリリースする度に1ずつ増やしていくようにしてください。この変数は同じバージョンのソースから次のパッケージを作成するときに差を示すために使われます。最初にリリースしたパッケージに問題やミスが含まれているかもしれない場合、次のリリースを作成したとき、pkgrelは1にリセットします。
  • pkgdescには短かい(通常76文字未満の)、パッケージの説明を記述します。通常、プログラムの名前を入れる必要はありません。つまり、OpenGL accelarated X serverという記述はxgl is OpenGL...よりも良い記述であるということです。
  • archにはアーキテクチャ名の配列を、普通は'i686'とし、PKGBUILDがどのアーキテクチャで動くかを記述します。パッケージ作成中には$archでこの変数にアクセスすることができます。
  • urlには更なる情報を求める利用者の助けになるよう、このプログラムのオフィシャルサイトのアドレスを設定します。
  • licenseにはライセンスの種類を記述します。もし分からない場合は'unknown'としてください。/usr/share/locenses/common/以下にあるライセンス名を使って下さい。(GPLやCCPLなど)
  • 'groups'にはパッケージが所属するグループを記述します。例えばkdebaseパッケージをインストールする場合、kdeグループに所属する全てのパッケージをインストールすることになります。
  • dependsにはこのプログラムが実行される前にインストールされる必要のあるパッケージ名を配列で(スペースによる区切りで)記述します。パッケージ名はシングルクォートで囲むことができます。配列は丸括弧で囲みます。プログラムによっては、特定のバージョンに依存していることがありますが、その場合はシングルクォート内で数学の不等号記号を使うことができます。例えば、glibcパッケージと1.8.0以上のバージョンのslangパッケージに依存している場合、depends=('glibc' 'slang>=1.8.0')と記述します。
  • makedependsには、パッケージ作成時にのみ必要で*インストール後には不要な*パッケージ名の配列を記述します。 例えば、パッチを解凍するときに必要なunarjなどを記述します。
  • optdependsには、このパッケージの動作に不可欠ではないけれども、インストールすると機能が追加されるパッケージを記述します。現在、pacmanはこの情報を利用者に通知する目的でしか使用しません(```depends```と異なり、依存性の解決には使われません)。書式は次のようにします: optdepends=('fakeroot: for makepkg usage as normal user')
  • providesには、このパッケージが提供するパッケージ名、あるいは'sh'や'cron'などの仮想的なパッケージ名を配列で記述します。この変数を使うとき、バージョンに依存した問題がある場合にはバージョン情報(pkgverやpkgrel)も記述しなければなりません。

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を作成した場合、provides=('qt=3.3.8')と記述します。provides=('qt')だけでは特定のバージョンのqtを必要とする依存関係を解決することができません。
例2: パッケージperl-5.10.0がperlのモジュールであるperl-foo 5.2.1とperl-bar 2.5も提供する場合、provides=('perl-foo=5.2.1' 'perl-bar=2.5')と記述します。

  • conflictsには、一緒にインストールすると問題を起こすパッケージ名を配列で記述します。dependsと同様にバージョンの情報を指定することができます。
  • replacesにはこのパッケージによって置き換えられる古いパッケージを配列で記述します。
  • backup
    • このパッケージが削除されるときfile.pacsaveという名前でバックアップされるファイルを配列で記述します。/etc以下の設定ファイルをインストールするパッケージで広く使われています。
  • options
    • この変数はmakepkgのデフォルトの振る舞いを上書きします。設定したいオプションを配列で指定します。デフォルトのオプションを無効にするには頭に!を付けます。以下のオプションが指定できます。
      • strip - バイナリとライブラリからシンボルを除去します
      • docs - /docsディレクトリを残します
      • libtool - libtoolファイル(.la)をパッケージに残します
      • emptydirs - 空ディレクトリをパッケージに残します
      • zipman - maninfoページをgzipで圧縮します
      • ccache - ビルド中にccacheを使うことを許可します。否定形の!ccacheは、ccacheを使ったビルドに問題がある場合に便利です。
      • distcc - ビルド中にdistccを使うことを許可します。否定形の!distccは、distccを使ったビルドに問題がある場合に便利です。
      • makeflags - ビルド中に利用者が指定するmakeflagsを使うことを許可します。否定形の!makeflagsは、makeflagsを使ったビルドに問題がある場合に便利です。
      • force - アップグレードする必要のないバージョンであっても強制的にpacmanによるアップグレードを行うようにします。バージョン番号の付け方を変更する場合(あるいはアルファベットでのバージョン管理)に便利です。
  • install
    • .installスクリプトをパッケージに含めることができるようになります。pacmanはパッケージのインストール、削除、アップグレード時に実行されるスクリプトをパッケージに含めることができます。
  • source: パッケージ作成に必要なファイルを配列にして記述します。大抵のパッケージではHTTP/FTPのURLがダブルクォーテーションで囲まれて記述されます。PKGBUILDの雛型にはここまでに設定した変数がパッケージ名やバージョンを効果的に記述する方法が書いてあります。もしダウンロードできないファイルを供給する必要がある時(例えば自作のパッチ等)、PKGBUILDと同じディレクトリにそのファイルを置き、sourcesにファイル名を追加します。追加したパスは全てPKGBUILDからの相対パスとして扱われます。実際のビルドプロセスが始まる前に、ここに記述したファイルはダウンロードされるか存在をチェックされます。もしファイルが見つからない場合、makepkgは実行されません。
  • noextract
    • sourceにリストされたファイルのうち、makepkgによって展開されないものを配列で記述します。これはbsdtarで扱えないzipファイルなどに適用されます(訳者不理解:libarchiveunzipが行うようなランダムアクセスではなく、全てのファイルをストリームとして扱うのでbsdtarで処理できない?)。このような場合はmakedepends変数にunzipを追加し、以下の行をbuild()の最初に記述します:
cd $srcdir/$pkgname-$pkgver
unzip [source].zip
  • md5sumsにはソースファイルのmd5チェックサムを配列で記述します。ソースファイルが全て利用可能な状態にあれば、それぞれのファイルに対するmd5ハッシュが自動的に生成され、結果がこの変数と比較されます。配列の並びはsourcesの並びと同じである必要があります。ソースファイルの順番が問題になることはありませんが、makepkgはどのmd5sumがどのソースファイルから生成されたかを推定せず、以前のダウンロードエラーや操作によって失敗している場合でも喜んでエラーを吐き出すので、md5sumsの順番は重要です(訳者不理解な一文)。sourceをちゃんとセットした後にPKGBUILDのあるディレクトリでmakepkg -gとすると、自動的にmd5sumsを出力してくれます。makepkg -g >>PKGBUILDとするとmd5sumを計算し、PKGBUILDの末尾に記述されるので、適切な行に移動させて下さい。

ここまで、パッケージのメタ情報(どこからソースを入手するか、名前は何か等など)を記述してきました。次のステップでは、パッケージングしようとしているプログラムをどのようにコンパイル&インストールするのか、その方法を説明します。

ソースの使用

ソースのtarballをダウンロードし、展開、そして必要なコマンド全てを記述してきました。PKGBUILDの関数build()の中では、これらの操作の実際と、コンパイルが終わったときに全てをパックするための一工夫を行います。

関数build()はbashの文法と同じシェルスクリプトを使います。この関数の主な目的はプログラムの自動的なコンパイルとインストール先であるpkgディレクトリの作成です。makepkgは現在稼働中のファイルシステムからは何も取り出さず、pkg以下のファイルだけをパッケージングします。

関数build()

通常、関数build()で最初に行われることはソースファイルを解凍した先のディレクトリに移動することです。この操作には変数"$startdir"を利用することができます(ダブルクォートで囲めばディレクトリ名にスペースを含んでいても安心です)。"$startdir"PKGBUILDの置かれているディレクトリへのパスになります。又、上の方で設定した$pkgname$pkgverを使うこともできます。例えば、makepkgで解凍されてできたディレクトリ名に対応して、関数buildの最初にcd "${srcdir}/$pkgname-$pkgver"と記述することで解凍されたソースディレクトリに移動することができます。これは、プログラムの作者が邪悪極まりない者でない限り使えるテクニックです。 バージョン番号にダッシが含まれている場合($pkgverはダッシを含めることができません)、$pkgverの代わりに"${pkgver//_/-}"として、アンダースコアをダッシに置き換えます。

プログラムのコンパイルはもっと難解な部分です。想定し得る全ての工程を網羅することは不可能なので、私はあなたが手作業でコンパイルを無事に終えることができることを想定しています。つまり、プログラムの作者がREADMEとINSTALLファイルを書いていてくれることを前提にしています。

解凍先のディレクトリにいけたとしましょう。次はどのようなコマンドを使ってソースをコンパイルするのかが問題になります。ソースが簡単な場合、./configure; makeで済みますが、ant buildgccを使う場合など、様々な場合があります。

幸いなことに、もし既にパッケージを手作業でコンパイルすることができているのなら、基本的にはコンパイルに使ったコマンドを書き連ねるだけでうまくいきます。多くのパッケージはファイルを/usr/local以下にインストールしたがりますが、Arch Linuxでは、pacmanで管理されるパッケージは/usr以下にインストールを行う方が好ましいです。ですから、そのように取り計らうためにconfigureスクリプトやmakeコマンドに対してパラメータを与える必要が出てくることがあります。PKGBUILDのひな型に一例があります。けれども、おそらくひな型のままではうまく行かないでしょう。繰り返しますが、コンパイルの作業過程は様々なのです。

  • 手動でパッケージをインストールする場合は--prefix=/usr/localを指定し、/usrはpacmanの管理するパッケージのために保護しておきましょう。パッケージのコンフリクトに頭を痛ませないで済むようになります。

関数build()で行う次の作業は、 コンパイルしたファイルをmakepkgがパッケージングできる場所に置くことです。その場所とはpkgディレクトリです。このディレクトリは単なるfake root環境です。すなわち、このディレクトリはインストール先のファイルシステムの/に相当します。インストールするファイルは全てpkg以下に、ディレクトリ構造を保ったまま置かれる必要があります(例えば、myprog/usr/binにインストールさせたい場合は${pkgdir}/usr/binmyprogを置きます)。幸いなことに、ほとんどのプログラムは手動でファイルをpkgディレクトリ以下にコピーする必要はありません。大抵は必要なファイルを自動的にインストールする手段("make install"等)が提供されています。しかしながら、用意されているインストール方法に対して/ではなく${pkgdir}/以下にインストールさせるように教えることは非常に重要です!もしこれを間違えると空のパッケージファイルしか生成されず、プログラムのバイナリはあなたのシステムに"正しく"インストールされてしまいます。ひな型にあるように"make install"とするときは殆どの場合prefixパラメータを指定してやる必要があるでしょう。しかしながら、あなたがパッケージングしたいプログラムが全く別の方法をとっていることがままあります。以下のヒントを参考にしてください。

  • configureスクリプトが、どこにファイルをインストールしなければならないかを決めるprefixプロパティを受け付けていることがあります。そのような場合、./configure --prefix=${pkgdir}/usrと記述します。
  • Sometimes the configure script accepts a prefix property that tells where the files should be installed. You might use ./configure --prefix=${pkgdir}/usr in such configuration, for example. Be certain that this is the right directory; sometimes the uncompressed directory might be named differently):
tar -xf foo-0.99.tar.gz

and a ls might return:

  .
  ..
  foo-0.99.tar.gz
  foo/

and not:

  .
  ..
  foo-0.99.tar.gz
  foo-0.99/
  • Sometimes there is a PREFIX option to append to a make install command. This is sometimes set as a variable, and sometimes set in the command. In worse cases you have to edit the Makefile(s) (or ant build/properties files if the project uses ant) with sed or a patch you'd have to create yourself.
  • There might be other sorts of install scripts that allow you to specify where the program should be installed.
  • In some cases, the program expects to be run from a single directory. Often it is wise to simply copy these to ${pkgdir}/opt.

As you might have guessed already, that's the part where actual knowledge and experience becomes a necessity. It helps a lot if you browse over the PKGBUILD files in the ABS tree, as those are tested and contain a few tricks that might prove valuable.

More often that not, the installation routine of the program will take care to create any subdirectories below the pkg/ directory. If it does not, however, you'll get a lot of errors during the install stage as files are copied to nonexistent subdirectories. In that case you'll have to create the needed subdirectories by adding the appropriate mkdir commands in the build() function before running the installation procedure. The actual directory structure is package dependent, of course; some programs need to place files in /etc or /usr while others might need to use /bin or /opt. Most will need to create several directories. You can do all of this with the mkdir -p ${pkgdir}/OTHER/DIRS/AS/NEEDED command, where OTHER/DIRS/AS/NEEDED represent directories at the root of the filesystem.

NB: makepkg, and thus the build() function, is intended to be non-interactive. Interactive utilities or scripts called in the build() function may break makepkg, particularly if it is invoked with build-logging enabled (-l). (see Arch Linux Bug #13214.)


The .install File: For Install Time Actions

If post-install steps are required for functionality, or for user-message output, you will need to use an .install file.

Specify the .install file by including the following in your PKGBUILD:

install=${pkgname}.install

Next, create a (pkgname).install file. A prototype .install is provided at /usr/share/pacman/proto.install to help you get started:

 # This is a default template for a post-install scriptlet.
 # Uncomment only required functions and remove any functions
 # you don't need (and this header).
 ## arg 1:  the new package version
 #pre_install() {
   # do something here
 #}
 ## arg 1:  the new package version
 #post_install() {
   # do something here
 #}
 ## arg 1:  the new package version
 ## arg 2:  the old package version
 #pre_upgrade() {
   # do something here
 #}
 ## arg 1:  the new package version
 ## arg 2:  the old package version
 #post_upgrade() {
   # do something here
 #}
 ## arg 1:  the old package version
 #pre_remove() {
   # do something here
 #}
 ## arg 1:  the old package version
 #post_remove() {
   # do something here
 #}
 # vim:set ts=2 sw=2 et:

Testing the PKGBUILD

As you are writing the PKGBUILD's 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. With a properly formatted PKGBUILD, this will create a package, but with a broken or unfinished one it will throw an error. Hopefully it will be a descriptive error!

If running makepkg finished successfully, it will place a shiny new file called $pkgname-$pkgver.pkg.tar.gz in your working directory. This is a pacman package and can be installed with the pacman -U and pacman -A options, or added to a local or web based repository. Note that just because a package file was built it doesn't mean it works! It might conceivably contain only the directory structure and no files whatsoever if, for example, you specified a prefix improperly. You can use pacman's query functions to display a list of files contained in the package and the dependencies it requires, and compare those with what you consider as correct. "pacman -Qlp <package file>" and "pacman -Qip <package file>" do the trick.

If the package looks sane, that's all you need to do. However, if you plan on releasing the package or PKGBUILD, it is imperative that you check and double check and re-double-check the contents of the depends array. This should contain a list of all packages that need to be installed in order for your package to work. You only need to list first level depends in the depends array. That is, you do not need to list packages that your program depends on if other packages that your program depends on are already listed.

For example, gtk2 depends on glib2. Like most open source C programs, it also requires glibc to be installed. However, glibc does not need to be listed as a dependency for gtk2 because it is a dependency for glib2, and glib2 is already listed in gtk2.

There are some tools you can use to check dependencies, including Jason Chu's famous namcap program (pacman -S namcap), and the more arcane ldd program. Check the man pages for these programs and the links at the end of this document for more information. You should also scour the program's documentation and website (some nice developers have a page called "dependencies" that helps a lot).

Testing the package

Also make sure that the package binaries actually run flawlessly! It's really annoying to release a package that contains all necessary files, but dumps core because of some obscure configuration option that doesn't quite work well with the rest of the system. If you're only going to compile packages for your own system, though, you don't need to worry too much about this quality assurance step, as you're the only person suffering from mistakes after all.

To sum it all up

  • Download the source tarball of the program you want to package up
  • Try compiling the package and installing it into an arbitrary directory
  • Copy over the prototype /usr/share/pacman/PKGBUILD.proto and rename it to PKGBUILD in a temporary working directory
  • Edit the PKGBUILD according to the needs of your package
  • Run makepkg and see whether the resulting package is built correctly
  • If not, repeat the last two steps

Useful links

Warnings

  • Before you can automate the package building process, you should have done it manually at least once unless you know exactly what you're 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 can't get the program to compile from the source tarball, and make it install itself to a defined, temporary subdirectory, you don't even need to try packaging it. There isn't 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 build() function, or you might have to issue some sed commands from inside the build() function.
  • Note that just because a package file was built it doesn't mean it works! It might conceivably contain only the directory structure and no files whatsoever if, for example, you specified a prefix improperly. You can use pacman's query functions to display a list of files contained in the package and the dependencies it requires, and compare those with what you consider as correct. "pacman -Qlp <package file>" and "pacman -Qip <package file>" do the trick.