「PKGBUILD」の版間の差分
(→パッケージの関係性: 情報を更新) |
|||
(5人の利用者による、間の21版が非表示) | |||
9行目: | 9行目: | ||
[[it:PKGBUILD]] |
[[it:PKGBUILD]] |
||
[[pl:PKGBUILD]] |
[[pl:PKGBUILD]] |
||
+ | [[pt:PKGBUILD]] |
||
[[ru:PKGBUILD]] |
[[ru:PKGBUILD]] |
||
[[sr:PKGBUILD]] |
[[sr:PKGBUILD]] |
||
− | [[zh- |
+ | [[zh-hans:PKGBUILD]] |
− | [[zh- |
+ | [[zh-hant:PKGBUILD]] |
{{Related articles start}} |
{{Related articles start}} |
||
{{Related|Arch パッケージングスタンダード}} |
{{Related|Arch パッケージングスタンダード}} |
||
{{Related|Arch Build System}} |
{{Related|Arch Build System}} |
||
{{Related|パッケージの作成}} |
{{Related|パッケージの作成}} |
||
+ | {{Related|.SRCINFO}} |
||
{{Related|:カテゴリ:パッケージ開発}} |
{{Related|:カテゴリ:パッケージ開発}} |
||
{{Related|カスタムローカルリポジトリ}} |
{{Related|カスタムローカルリポジトリ}} |
||
25行目: | 27行目: | ||
{{Related articles end}} |
{{Related articles end}} |
||
+ | この記事では {{ic|PKGBUILD}} の中でメンテナが定義できる変数について説明します。{{ic|PKGBUILD}} の関数や一般的なパッケージの作成については [[パッケージの作成]] を参照してください。{{man|5|PKGBUILD}} も読んで下さい。 |
||
− | '''PKGBUILD''' は[[パッケージの作成|パッケージを作成]]するときに使われる [[Arch Linux]] のパッケージビルド記述ファイルです (中身はシェルスクリプトです)。 |
||
+ | {{ic|PKGBUILD}} はシェルスクリプトで、[[Arch Linux]] のパッケージが必要とするビルド情報を含んでいます。 |
||
− | Arch Linux では [[makepkg]] ユーティリティと PKGBUILD 内の情報を使ってパッケージがビルドされます。'''makepkg''' が実行されると、作業ディレクトリ内で {{Ic|PKGBUILD}} が検索されその中の記述に従ってコンパイルしたりファイルを取得してパッケージファイル ({{ic|''pkgname''.pkg.tar.xz}}) が作成されます。作られたパッケージにはバイナリファイルとインストールの記述が含まれており、[[pacman]] によって読み込まれインストールされます。 |
||
+ | Arch Linux のパッケージは [[makepkg]] ユーティリティを使ってビルドされます。''makepkg'' を実行すると、カレントディレクトリにある {{ic|PKGBUILD}} ファイルを探し、その中の指示に従ってコンパイルするか、パッケージアーカイブ ({{ic|''pkgname''.pkg.tar.zst}}) を構築するためのファイルを入手します。出来上がったパッケージにはバイナリファイルとインストール手順が含まれ、[[pacman]] で簡単にインストールできます。 |
||
− | この記事では PKGBUILD で使用する変数について扱っています。PKGBUILD の関数についての情報は、[[パッケージの作成#PKGBUILD の関数]]を参照してください。 |
||
+ | 必須の変数は、{{ic|pkgname}}、{{ic|pkgver}}、{{ic|pkgrel}}、および {{ic|arch}} です。 {{ic|license}} は、パッケージをビルドするために厳密に必要というわけではありませんが、''makepkg'' が存在しない場合に警告を生成するため、他のユーザーと共有する {{ic|PKGBUILD}} には推奨されます。 |
||
− | == 変数 == |
||
− | PKGBUILD ファイルの中で使うことができる変数は以下の通りです。 |
||
+ | ここで指定された順番で {{ic|PKGBUILD}} の変数を定義するのが一般的なやり方です。しかし、正しい [[Bash]] 構文が使われている限り、これは必須ではありません。 |
||
− | {{ic|pkgname}}, {{ic|pkgver}}, {{ic|pkgrel}}, {{ic|arch}} は全て必須です。{{ic|license}} はパッケージのビルドには必須ではありませんが、他の人と共有したい PKGBUILD には含めるのが推奨されています。存在しない場合 {{ic|makepkg}} は警告を表示します。 |
||
+ | {{Tip|{{ic|PKGBUILD}} によくあるパッケージングの間違いがないかチェックするには [[namcap]] を使って下さい。}} |
||
− | PKGBUILD 内では変数をこのページと同じ順番で定義するのが通例となっています。ただし、それは必須ではなく、[[Bash]] の構文が正しければ問題ありません。 |
||
== パッケージ名 == |
== パッケージ名 == |
||
42行目: | 43行目: | ||
=== pkgbase === |
=== pkgbase === |
||
+ | 通常のパッケージをビルドするときは、この変数を {{ic|PKGBUILD}} で明示的に宣言してはいけません: |
||
− | 分割パッケージを作成するときに使うことができる、任意のグローバルディレクティブ。{{ic|pkgbase}} を使うことで ''makepkg'' の出力とソース tarball の名でパッケージのグループを参照することができます。pkgbase が指定されていない場合、{{ic|pkgname}} 変数の最初のエレメントが使われます。この変数の先頭の文字をハイフンにすることはできません。分割パッケージの全ての値はデフォルトで PKGBUILD に指定されたグローバルな値になります。[[#makedepends]], [[#ソース]], [[#整合性]] の変数を除く、全ての変数を分割パッケージの {{ic|package()}} 関数で上書きすることができます。 |
||
+ | この変数のデフォルトの値は [[PKGBUILD#pkgname|pkgname]] の値です。 |
||
+ | |||
+ | [https://man.archlinux.org/man/PKGBUILD.5#PACKAGE_SPLITTING 分割パッケージ] をビルドするときは、この変数を使って ''makepkg'' の出力やソースだけの tarball の名前付けにパッケージのグループを参照するために使う名前を明示的に指定できます。この値はハイフンで始めることはできません。指定しない場合、値はデフォルトで {{ic|pkgname}} 配列の最初の要素になります。 |
||
+ | |||
+ | 分割パッケージのすべてのオプションとディレクティブのデフォルトは {{ic|PKGBUILD}} で指定されたグローバルな値です。ただし、以下のものは各分割パッケージのパッケージング関数の中でオーバーライドすることができます。[[PKGBUILD#pkgdesc|pkgdesc]], [[PKGBUILD#arch|arch]], [[PKGBUILD#url|url]], [[PKGBUILD#license|license]], [[PKGBUILD#groups|groups]], [[PKGBUILD#depends|depends]], [[PKGBUILD#optdepends|optdepends]], [[PKGBUILD#provides|provides]], [[PKGBUILD#conflicts|conflicts]], [[PKGBUILD#replaces|replaces]], [[PKGBUILD#backup|backup]], [[PKGBUILD#options|options]], [[PKGBUILD#install|install]] そして [[PKGBUILD#changelog|changelog]] |
||
=== pkgname === |
=== pkgname === |
||
− | パッケージの名前。含めることができる文字は、小文字の英数字と以下の記号です: {{ic|@}}, {{ic|.}}, {{ic|_}}, {{ic|+}}, {{ic|-}} (アットマーク、ドット、アンダーバー、プラス、ハイフン)。全ての文字は''小文字''でなくてはならず''名前の最初をハイフンにすることはできません''。一貫性を保つために、{{ic|pkgname}} はパッケージするソース tarball の名前と一致させてください。例えば、ソフトウェアが {{ic|foobar-2.5.tar.gz}} なら、{{ic|pkgname}} の値は {{Ic|foobar}} にするべきです。PKGBUILD ファイルを入れる作業ディレクトリも {{ic|pkgname}} と一致させる必要があります。 |
||
+ | パッケージの名前、例えば {{ic|1=pkgname='foo'}} か、分割パッケージの場合は名前の配列、例えば {{ic|1=pkgname=('foo' 'bar')}} を指定します。パッケージ名は小文字の英数字と以下の文字のみで構成されている必要があります。{{ic|@._+-}} は小文字の英数字と以下の文字で構成されています。(アットマーク、ドット、アンダースコア、プラス、ハイフン) ハイフンやドットで名前を始めることはできません。一貫性を保つために、{{ic|pkgname}} はソフトウェアのソース tarball の名前と一致させるべきです。例えば、ソフトウェアが {{ic|foobar-2.5.tar.gz}} に入っているならば、{{ic|1=pkgname=foobar}} と記述して下さい。 |
||
− | 分割パッケージは配列として定義します。例: {{ic|1=pkgname=('foo' 'bar')}}。 |
||
== バージョン == |
== バージョン == |
||
57行目: | 62行目: | ||
{{Note|ソフトウェアの開発元が {{ic|30102014}} のようなタイムスタンプによるバージョン付けをしている場合、日付の順序を逆にしてください: {{ic|20141030}} ([[Wikipedia:ISO 8601|ISO 8601]] 形式)。そうしないと新しいバージョンが認識されません。}} |
{{Note|ソフトウェアの開発元が {{ic|30102014}} のようなタイムスタンプによるバージョン付けをしている場合、日付の順序を逆にしてください: {{ic|20141030}} ([[Wikipedia:ISO 8601|ISO 8601]] 形式)。そうしないと新しいバージョンが認識されません。}} |
||
+ | {{Tip| |
||
− | {{Tip|PKGBUILD に {{ic|pkgver()}} 関数を定義することで [[makepkg]] は自動的に pkgver 変数を [http://allanmcrae.com/2013/04/pacman-4-1-released/ 更新] します。詳しくは [[VCS パッケージガイドライン#関数 pkgver()]] を見て下さい。}} |
||
+ | * [[pacman]] パッケージに含まれている [https://www.archlinux.org/pacman/vercmp.8.html vercmp] を使うことでバージョンの優先度をテストできます。 |
||
+ | * PKGBUILD に {{ic|pkgver()}} 関数を定義することで [[makepkg]] は自動的に pkgver 変数を [http://allanmcrae.com/2013/04/pacman-4-1-released/ 更新] します。詳しくは [[VCS パッケージガイドライン#関数 pkgver()]] を見て下さい。}} |
||
=== pkgrel === |
=== pkgrel === |
||
− | Arch Linux におけるパッケージのリリース番号。パッケージの同じバージョンを続けてビルドするときにそれを区別するためにこの値を使います。新しいバージョンのパッケージが始めてリリースされたとき、'''リリース番号は1からスタートします'''。{{ic|PKGBUILD}} ファイルに修正や最適化が加えられるたびに、パッケージは'''再リリース'''され'''リリース番号'''は |
+ | Arch Linux におけるパッケージのリリース番号。パッケージの同じバージョンを続けてビルドするときにそれを区別するためにこの値を使います。新しいバージョンのパッケージが始めてリリースされたとき、'''リリース番号は1からスタートします'''。{{ic|PKGBUILD}} ファイルに修正や最適化が加えられるたびに、パッケージは'''再リリース'''され'''リリース番号'''は1づつ増やされます。新しいバージョンのパッケージが出たら、リリース番号は1にリセットします。 |
=== epoch === |
=== epoch === |
||
80行目: | 87行目: | ||
=== pkgdesc === |
=== pkgdesc === |
||
− | パッケージの説明。説明は80文字以下でなくてはならず、また説明の中にパッケージ名を含めて自己参照してはいけません。例えば、"Nedit is a text editor for X11" は "A text editor for X11" に書き換えてください。 |
||
+ | パッケージの説明。これは 80 文字以下にすることをお勧めします。また、アプリケーション名がパッケージ名と異なる場合を除き、パッケージ名を自己参照的に含めないでください。たとえば、{{ic|1=pkgdesc="Nedit is a text editor for X11"}} の代わりに {{ic|1=pkgdesc="Text editor for X11"}} を使用します。 |
||
− | {{Note|[[Arch User Repository|AUR]] にパッケージを投稿するときは、このルールにむやみに従ってはいけません。何らかの理由でパッケージの名前がアプリケーションの名前と異なる場合、検索でパッケージを表示する唯一の方法はフルネームを説明に入れることです。}} |
||
+ | |||
+ | また、キーワードを賢く使用して、関連する検索クエリに表示される可能性を高めることも重要です。 |
||
=== arch === |
=== arch === |
||
− | {{ic|PKGBUILD}} がビルド・動作するアーキテクチャの文字列。現在、{{ic|i686}} と {{ic|x86_64}} が使えます。ただし、[ |
+ | {{ic|PKGBUILD}} がビルド・動作するアーキテクチャの文字列。現在、{{ic|i686}} と {{ic|x86_64}} が使えます。ただし、[https://archlinuxarm.org/ Arch Linux ARM] などのプロジェクトでは他のアーキテクチャもサポートしています: {{ic|arm}} (armv5), {{ic|armv6h}} (armv6 hardfloat), {{ic|armv7h}} (armv7 hardfloat), {{ic|aarch64}} (armv8 64bit)。 |
アーキテクチャに依存しないパッケージ (シェルスクリプト, フォント, テーマなど) には {{ic|any}} を使うことができます。{{ic|-i686}} や {{ic|-x86_64}} とは対照的に、一度ビルドしたら他のアーキテクチャでも使うことができるようなパッケージには {{ic|-any}} を指定してください。全てのアーキテクチャに対応するようにパッケージをコンパイルすることができても、特定のアーキテクチャに向けてコンパイルされる場合は、Arch によって公式にサポートされているアーキテクチャを指定してください: {{ic|1=arch=('i686' 'x86_64')}}。 |
アーキテクチャに依存しないパッケージ (シェルスクリプト, フォント, テーマなど) には {{ic|any}} を使うことができます。{{ic|-i686}} や {{ic|-x86_64}} とは対照的に、一度ビルドしたら他のアーキテクチャでも使うことができるようなパッケージには {{ic|-any}} を指定してください。全てのアーキテクチャに対応するようにパッケージをコンパイルすることができても、特定のアーキテクチャに向けてコンパイルされる場合は、Arch によって公式にサポートされているアーキテクチャを指定してください: {{ic|1=arch=('i686' 'x86_64')}}。 |
||
100行目: | 108行目: | ||
=== license === |
=== license === |
||
− | ソフトウェアが配布されるライセンス。{{ic|[core]}} の {{pkg|licenses}} パッケージは {{ic|/usr/share/licenses/common}} によく使われるライセンスを保存しています、例えば {{ic|/usr/share/licenses/common/GPL}}。パッケージのライセンスがここに保存されているライセンスのどれかのときは、ディレクトリの名前を設定してください、例えば {{ic|1=license=('GPL')}}。適切なライセンスが公式の {{Pkg|licenses}} パッケージに含まれていない場合は、やる必要があることがいくつかあります: |
||
+ | ソフトウェアが配布されるライセンス。{{ic|[core]}} の {{pkg|licenses}} パッケージは {{ic|/usr/share/licenses/common}} によく使われるライセンスを保存しています、例えば {{ic|/usr/share/licenses/common/GPL}} パッケージのライセンスがここに保存されているライセンスのどれかのときは、ディレクトリの名前を設定してください、例えば {{ic|1=license=('GPL')}} 適切なライセンスが公式の {{Pkg|licenses}} パッケージに含まれていない場合は、やる必要があることがいくつかあります: |
||
− | # ライセンスファイルを次のディレクトリに含めなくてはなりません: {{ic|/usr/share/licenses/''pkgname''/}}, 例 {{ic|/usr/share/licenses/foobar/LICENSE}}。 |
||
+ | |||
+ | # ライセンスファイルを次のディレクトリに含めなくてはなりません: {{ic|/usr/share/licenses/''pkgname''/}}, 例 {{ic|/usr/share/licenses/foobar/LICENSE}} |
||
# ソース tarball にライセンスの詳細が含まれずウェブサイトなど他のところで示されている場合は、ライセンスをファイルにコピーしてそのファイルを含めて下さい。 |
# ソース tarball にライセンスの詳細が含まれずウェブサイトなど他のところで示されている場合は、ライセンスをファイルにコピーしてそのファイルを含めて下さい。 |
||
− | # {{ic|license}} 行に {{ic|custom}} を追加してください。任意で、{{ic|custom}} を {{ic|custom:ライセンスの名前}} にすることができます。あるライセンスが ({{ic|[community] を含む}}) 公式リポジトリの |
+ | # {{ic|license}} 行に {{ic|custom}} を追加してください。任意で、{{ic|custom}} を {{ic|custom:ライセンスの名前}} にすることができます。あるライセンスが ({{ic|[community] を含む}}) 公式リポジトリの2つ以上のパッケージで使われると、{{Pkg|licenses}} パッケージに入れられます。 |
− | * 特別な事例として [[Wikipedia:ja:BSDライセンス|BSD]], [[Wikipedia:ja:MIT License|MIT]], [[Wikipedia:ja:zlib License|zlib/png]], [[Wikipedia:ja:Python Software Foundation License|Python]] ライセンスは {{pkg|licenses}} パッケージに含められていません。{{ic|license}} 行の目的のために、一般的なライセンス ({{ic|1=license=('BSD')}}, {{ic|1=license=('MIT')}}, {{ic|1=license=('ZLIB')}}, {{ic|1=license=('Python')}}) として扱われておきながらそれぞれ固有の copyright 行を持っているために技術的にカスタムライセンスになっています。これら4つのライセンスを使っている全てのパッケージは {{ic|/usr/share/licenses/''pkgname''}} 内にそのライセンスを保存しておく必要があります。パッケージによってはライセンスがひとつだけではないこともあります。そのような場合は、license 行に複数のエントリを書くことができます、例えば {{ic|1=license=('GPL' 'custom:name of license')}} |
+ | * 特別な事例として [[Wikipedia:ja:BSDライセンス|BSD]], [[Wikipedia:ja:MIT License|MIT]], [[Wikipedia:ja:zlib License|zlib/png]], [[Wikipedia:ja:Python Software Foundation License|Python]] ライセンスは {{pkg|licenses}} パッケージに含められていません。{{ic|license}} 行の目的のために、一般的なライセンス ({{ic|1=license=('BSD')}}, {{ic|1=license=('MIT')}}, {{ic|1=license=('ZLIB')}}, {{ic|1=license=('Python')}}) として扱われておきながらそれぞれ固有の copyright 行を持っているために技術的にカスタムライセンスになっています。これら4つのライセンスを使っている全てのパッケージは {{ic|/usr/share/licenses/''pkgname''}} 内にそのライセンスを保存しておく必要があります。パッケージによってはライセンスがひとつだけではないこともあります。そのような場合は、license 行に複数のエントリを書くことができます、例えば {{ic|1=license=('GPL' 'custom:name of license')}} |
* さらに、(L)GPL には多くのバージョンと組み合わせが存在します。(L)GPL ソフトウェアで使えるのは: |
* さらに、(L)GPL には多くのバージョンと組み合わせが存在します。(L)GPL ソフトウェアで使えるのは: |
||
** (L)GPL - (L)GPLv2 とそれ以降のバージョン |
** (L)GPL - (L)GPLv2 とそれ以降のバージョン |
||
112行目: | 121行目: | ||
* license が決められていないと、{{ic|PKGBUILD.proto}} は {{ic|unknown}} を使うことを提案します。ただし、ソフトウェアが利用できるかできないかについてはアップストリームに連絡をすべきです。 |
* license が決められていないと、{{ic|PKGBUILD.proto}} は {{ic|unknown}} を使うことを提案します。ただし、ソフトウェアが利用できるかできないかについてはアップストリームに連絡をすべきです。 |
||
− | {{Tip|ソフトウェアの作者によってはライセンスファイルを作らずに普通の {{ic|ReadMe.txt}} の中に配布ルールについて記述しているかもしれません。{{Ic|build()}} フェイズの時に、次のようにすることでファイルにこの情報を展開することが可能です: {{Ic|sed -n '/'''This software'''/,/''' thereof.'''/p' ReadMe.txt > LICENSE}} |
+ | {{Tip|ソフトウェアの作者によってはライセンスファイルを作らずに普通の {{ic|ReadMe.txt}} の中に配布ルールについて記述しているかもしれません。{{Ic|build()}} フェイズの時に、次のようにすることでファイルにこの情報を展開することが可能です: {{Ic|sed -n '/'''This software'''/,/''' thereof.'''/p' ReadMe.txt > LICENSE}}}} |
+ | |||
+ | こちらも参照 [[ノンフリーアプリケーションパッケージガイドライン]] |
||
+ | |||
+ | フリーおよびオープン ソース ソフトウェア ライセンスに関する追加情報と展望は、次のページで見つけることができます。 |
||
+ | |||
+ | * [[Wikipedia:ja:自由ソフトウェアライセンス|自由ソフトウェアライセンス]] |
||
+ | * [[Wikipedia:Comparison of free and open-source software licenses]] |
||
+ | * [https://www.softwarefreedom.org/resources/2008/foss-primer.html オープン ソースおよびフリー ソフトウェア プロジェクトの法的問題の入門書] |
||
+ | * [https://www.gnu.org/licenses/license-list.html GNU Project - さまざまなライセンスとそれらについての解説] |
||
+ | * [https://www.debian.org/legal/licenses/ Debian - ライセンス情報] |
||
+ | * [https://www.opensource.org/licenses/alphabetical Open Source Initiative - 名前別ライセンス] |
||
=== groups === |
=== groups === |
||
+ | |||
− | パッケージが属するグループ。例えば、{{Grp|kdebase}} パッケージをインストールすると、{{Grp|kde}} グループに含まれる全てのパッケージをインストールします。 |
||
+ | パッケージが属する [[メタパッケージとパッケージグループ|group]] たとえば、{{Grp|plasma}} をインストールすると、そのグループに属するすべてのパッケージがインストールされます。 |
||
== 依存関係 == |
== 依存関係 == |
||
145行目: | 166行目: | ||
== パッケージの関係性 == |
== パッケージの関係性 == |
||
− | {{Note|アンダーバーとアーキテクチャの名前を付けることで、特定のアーキテクチャだけのパッケージの関係性を追加することができます。例: {{ic|1=provides_x86_64=()}}, {{ic|1=conflicts_x86_64=()}} |
+ | {{Note|アンダーバーとアーキテクチャの名前を付けることで、特定のアーキテクチャだけのパッケージの関係性を追加することができます。例: {{ic|1=provides_x86_64=()}}, {{ic|1=conflicts_x86_64=()}}}} |
=== provides === |
=== provides === |
||
+ | |||
− | パッケージの機能を提供するパッケージ (もしくは {{Ic|cron}} や {{Ic|sh}} などの仮想パッケージ) の名前の文字列。同じものを提供するパッケージは互いに衝突しないかぎり同時にインストールすることができます(下を見て下さい)。この変数を使う場合は、バージョンによって影響を受ける依存関係がある場合パッケージが提供するバージョン ({{ic|pkgver}} と恐らく {{ic|pkgrel}}) を追加してください。例えば、''qt'' にモディファイを加えて ''qt'' を提供する ''qt-foobar'' バージョン 3.3.8 という名前で作成するときは、{{ic|provides}} 行は {{ic|1=provides=('qt=3.3.8')}} のようにしてください。{{ic|1=provides=('qt')}} とすると ''qt'' の特定バージョンを必要とする依存関係が破壊されることになります。{{ic|provides}} 行に {{ic|pkgname}} を加えないでください、自動で追加されます。 |
||
+ | パッケージの機能を提供するパッケージ (もしくは {{Ic|cron}} や {{Ic|sh}} などの仮想パッケージ) の名前の文字列。同じものを提供するパッケージは互いに衝突しないかぎり同時にインストールすることができます。 |
||
+ | |||
+ | {{Note|この変数を使う場合は、バージョンによって影響を受ける依存関係がある場合パッケージが提供するバージョン ({{ic|pkgver}} と恐らく {{ic|pkgrel}}) を追加してください。例えば、''qt'' にモディファイを加えて ''qt'' を提供する ''qt-foobar'' バージョン 3.3.8 という名前で作成するときは、{{ic|provides}} 行は {{ic|1=provides=('qt=3.3.8')}} のようにしてください。{{ic|1=provides=('qt')}} とすると ''qt'' の特定バージョンを必要とする依存関係が破壊されることになります。{{ic|provides}} 行に {{ic|pkgname}} を加えないでください、自動で追加されます。}} |
||
=== conflicts === |
=== conflicts === |
||
+ | |||
インストールするとパッケージと問題が生じるパッケージの名前の文字列。この名前を持つパッケージとこの名前の仮想パッケージを {{Ic|provides}} に入れている全てのパッケージが削除されます。{{ic|depends}} 行と同じフォーマットを使って衝突するパッケージのバージョンプロパティを指定することもできます。 |
インストールするとパッケージと問題が生じるパッケージの名前の文字列。この名前を持つパッケージとこの名前の仮想パッケージを {{Ic|provides}} に入れている全てのパッケージが削除されます。{{ic|depends}} 行と同じフォーマットを使って衝突するパッケージのバージョンプロパティを指定することもできます。 |
||
+ | |||
+ | 競合は、{{ic|pkgname}} および {{ic|provides}} 配列で指定された名前に対してチェックされることに注意してください。したがって、パッケージが {{ic|provides}} に {{ic|''foo''}} 機能を備えている場合、{{ic|conflicts}} 配列に {{ic|''foo''}} を指定すると、あなたのパッケージと、{{ic|provides}} 配列に {{ic|''foo''}} を含む他のすべてのパッケージとの間の競合 (つまり、競合するすべてのパッケージ名を {{ic|flicts}} 配列に指定する必要はありません) 具体的な例を挙げてみましょう。 |
||
+ | |||
+ | * {{Pkg|netbeans}} は暗黙的に {{ic|netbeans}} を {{ic|pkgname}} 自身として提供しています。 |
||
+ | * {{AUR|netbeans-cpp}} は {{ic|netbeans}} を提供し、{{ic|netbeans}} と衝突します。 |
||
+ | * {{AUR|netbeans-php}} は {{ic|netbeans}} を提供し、{{ic|netbeans}} と衝突しますが、同じ機能を提供するパッケージは暗黙のうちに衝突するので、明示的に {{AUR|netbeans-cpp}} と衝突する必要はありません。 |
||
+ | |||
+ | パッケージが {{ic|provides}} 配列を介して同じ機能を提供する場合、代替パッケージを {{ic|conflicts}} 配列に明示的に追加する場合と追加しない場合には違いがあります。{{ic|conflicts}} 配列が明示的に宣言されている場合、同じ機能を提供する 2 つのパッケージが ''代替'' とみなされます。{{ic|conflicts}} 配列が欠落している場合、同じ機能を提供する 2 つのパッケージが ''共存している可能性がある'' とみなされます。パッケージャは、{{ic|conflicts}} 変数を宣言するかどうかを決定する際に、{{ic|provides}} 変数の内容を常に無視する必要があります。 |
||
=== replaces === |
=== replaces === |
||
+ | |||
− | パッケージによって置き換えられる廃止パッケージの名前の文字列、例えば {{pkg|wireshark}} パッケージには {{ic|1=replaces=('ethereal')}}。{{ic|pacman -Sy}} で同期をした後、リポジトリ内の {{ic|replaces}} に一致する他のパッケージが現れるとインストールされたパッケージを置き換えます。既存のパッケージの別バージョンを提供するときは、衝突するパッケージをインストールするときに評価される {{ic|conflicts}} 変数を使って下さい。 |
||
+ | 例えば {{Pkg|wireshark-qt}} は {{ic|1=replaces=('wireshark')}} を使います。同期する時、''pacman'' はインストールされたパッケージがリポジトリで {{ic|replaces}} にマッチする別のパッケージに出会ったら即座に置き換えます。既にあるパッケージの別バージョンを提供したり AUR にアップロードする時は {{ic|conflicts}} と {{ic|provides}} 配列を使ってください。 |
||
== その他 == |
== その他 == |
||
161行目: | 195行目: | ||
ユーザーが作成した変更を含んだり、パッケージのアップグレードや削除が行われても維持されるファイルの文字列、主に {{ic|/etc}} 内の設定ファイル用。 |
ユーザーが作成した変更を含んだり、パッケージのアップグレードや削除が行われても維持されるファイルの文字列、主に {{ic|/etc}} 内の設定ファイル用。 |
||
− | アップデート時、既存のファイル |
+ | アップデート時、既存のファイル(ユーザーによって修正されたファイル)を上書きしないために新しいバージョンは {{ic|file.pacnew}} として保存されます。同じく、パッケージの削除時、パッケージを削除するのに {{ic|pacman -Rn}} コマンドを使わなければ、ユーザーが修正したファイルは {{ic|file.pacsave}} として残されます。 |
この行のファイルパスは絶対パス (例: {{ic|/etc/pacman.conf}}) ではなく相対パス (例: {{ic|etc/pacman.conf}}) にしてください。[[Pacnew と Pacsave ファイル]]も参照。 |
この行のファイルパスは絶対パス (例: {{ic|/etc/pacman.conf}}) ではなく相対パス (例: {{ic|etc/pacman.conf}}) にしてください。[[Pacnew と Pacsave ファイル]]も参照。 |
||
194行目: | 228行目: | ||
{{Tip|{{ic|.install}} のプロトタイプが {{ic|/usr/share/pacman/proto.install}} にあります。}} |
{{Tip|{{ic|.install}} のプロトタイプが {{ic|/usr/share/pacman/proto.install}} にあります。}} |
||
+ | |||
+ | {{Note|スクリプトの中で {{ic|exit}} を実行しないでください。スクリプト内の関数が実行できなくなってしまいます。}} |
||
=== changelog === |
=== changelog === |
||
243行目: | 279行目: | ||
以下の変数はどれもチェックサム文字列を指定するようになっており、[[#source|source]] 配列に書かれたファイルの整合性を確認するのに使われます。{{ic|SKIP}} とすることで特定のファイルのチェックサムを確認しないようにできます。 |
以下の変数はどれもチェックサム文字列を指定するようになっており、[[#source|source]] 配列に書かれたファイルの整合性を確認するのに使われます。{{ic|SKIP}} とすることで特定のファイルのチェックサムを確認しないようにできます。 |
||
+ | チェックサムの種類と値は、リリースアナウンスなど上流から提供されたものを常に使用する必要があります。複数のタイプが利用可能な場合は、最も強力なチェックサムが優先されます。{{ic|sha512}} よりも {{ic|b2}}, {{ic|sha384}} よりも {{ic|sha384}}, {{ic|sha256}} よりも {{ic|sha512}} を優先してください, {{ic|sha224}} に対して {{ic|sha256}}、{{ic|sha1}} に対して {{ic|sha224}}、{{ic|md5}} に対して {{ic|sha1}}、および {{ic|md5}} 以上 {{ic|ck}}} があります。これは、上流のアナウンスからパッケージのビルドまで、ダウンロードしたファイルの完全性を保証するために最適な方法です。 |
||
− | チェックサムが確認するのはあくまでダウンロードしたファイルの''整合性''であり、ファイルの''正統性''ではありません。そのため、例えば MD5 アルゴリズムには[[Wikipedia:ja:MD5#安全性|脆弱性]]があることが知られていますが、ファイルの確認だけに使うのであれば、SHA-2 ハッシュよりも高速に確認できるため使用が推奨されます (特にソースファイルのサイズが大きい場合)。ただし、可能であれば、{{ic|source}} 行に署名を追加してファイルの正統性も確認するようにしてください: 上で説明したように、その場合はチェックサムの確認は省くことができます。 |
||
+ | {{Note|さらに、上流が [[Wikipedia:ja:デジタル署名|デジタル署名]] を利用可能にしたら、署名ファイルを [[#source|source]] 配列に、PGP 鍵指紋を [[#validpgpkeys|validpgpkeys]] 配列に追加する必要があります。これにより、ビルド時にファイルの認証ができるようになります。}} |
||
− | チェックサムの値は [[makepkg]] の {{ic|-g}}/{{ic|--geninteg}} オプションで自動生成することができ、{{ic|makepkg -g >> PKGBUILD}} を使えば PKGBUILD に追加できます。また、{{ic|updpkgsums}} コマンドを使うことで、PKGBUILD のどの部分に変数を書いている場合でもチェックサムを更新することが可能です。どちらのツールも PKGBUILD に既に設定されている変数を使います。何も設定されていなかった場合は {{ic|md5sums}} を使います。 |
||
+ | これらの変数の値は [[makepkg]] の {{ic|-g}}/{{ic|--geninteg}} オプションで自動生成され、一般に {{ic|makepkg -g >> PKGBUILD}} で追加されます。{{Pkg|pacman-contrib}} の {{man|8|updpkgsums}} コマンドは {{ic|PKGBUILD}} 内のどこにあっても変数を更新することが可能です。どちらのツールも {{ic|PKGBUILD}} に既に設定されている変数を使い、設定されていない場合は {{ic|md5sums}} にフォールバックします。 |
||
− | ファイルの整合性の確認については {{ic|/etc/makepkg.conf}} の {{ic|INTEGRITY_CHECK}} オプションで設定が可能です。[https://www.archlinux.org/pacman/makepkg.conf.5.html makepkg.conf(5)] を参照してください。 |
||
+ | |||
+ | 使用するファイルの整合性チェックは {{ic|/etc/makepkg.conf}} の {{ic|INTEGRITY_CHECK}} オプションで設定することができます。 {{man|5|makepkg.conf}} を参照してください。 |
||
+ | |||
+ | {{Note|追加のアーキテクチャ固有の配列は、アンダースコアとアーキテクチャ名を付加することで追加できます、例えば {{ic|1=sha256sums_x86_64=() }}}} |
||
+ | |||
+ | === cksums === |
||
+ | {{ic|source}} 配列にリストされているファイルの [[Wikipedia:ja:巡回冗長検査|CRC32]] チェックサム (UNIX 標準 [[Wikipedia:ja:Cksum_(UNIX)|cksum]] より) |
||
=== md5sums === |
=== md5sums === |
||
− | {{ic|source}} 行に含まれるファイルの MD5 チェックサムの文字列。 |
+ | {{ic|source}} 行に含まれるファイルの 128 ビット [[Wikipedia:ja:MD5|MD5]] チェックサムの文字列。 |
=== sha1sums === |
=== sha1sums === |
||
− | 160ビットの SHA-1 チェックサムの文字列。 |
+ | {{ic|source}} 行に含まれるファイルの 160ビットの [[Wikipedia:SHA-1|SHA-1]] チェックサムの文字列。 |
=== sha256sums === |
=== sha256sums === |
||
− | [[Wikipedia:SHA-2|SHA-2]] チェックサムの配列 |
+ | ダイジェスト サイズが 256 ビットの [[Wikipedia:ja:SHA-2|SHA-2]] チェックサムの配列。 |
=== sha224sums, sha384sums, sha512sums === |
=== sha224sums, sha384sums, sha512sums === |
||
− | それぞれ 224, 384, 512 ビットのダイジェストサイズの SHA-2 チェックサムの文字列。{{ic|sha256sums}} の代替。 |
+ | それぞれ 224, 384, 512 ビットのダイジェストサイズの SHA-2 チェックサムの文字列。{{ic|sha256sums}} の代替ですが、あまり一般的ではない代替手段です。 |
+ | |||
+ | === b2sums === |
||
+ | [[Wikipedia:ja:BLAKE#BLAKE2|BLAKE2]] チェックサムの配列で、ダイジェスト サイズは 512 ビットです。 |
||
== 参照 == |
== 参照 == |
||
*[https://www.archlinux.org/pacman/PKGBUILD.5.html PKGBUILD(5) マニュアルページ] |
*[https://www.archlinux.org/pacman/PKGBUILD.5.html PKGBUILD(5) マニュアルページ] |
||
− | *[ |
+ | *[https://projects.archlinux.org/pacman.git/plain/proto/PKGBUILD.proto サンプル PKGBUILD ファイル] |
2023年8月3日 (木) 15:04時点における最新版
関連記事
この記事では PKGBUILD
の中でメンテナが定義できる変数について説明します。PKGBUILD
の関数や一般的なパッケージの作成については パッケージの作成 を参照してください。PKGBUILD(5) も読んで下さい。
PKGBUILD
はシェルスクリプトで、Arch Linux のパッケージが必要とするビルド情報を含んでいます。
Arch Linux のパッケージは makepkg ユーティリティを使ってビルドされます。makepkg を実行すると、カレントディレクトリにある PKGBUILD
ファイルを探し、その中の指示に従ってコンパイルするか、パッケージアーカイブ (pkgname.pkg.tar.zst
) を構築するためのファイルを入手します。出来上がったパッケージにはバイナリファイルとインストール手順が含まれ、pacman で簡単にインストールできます。
必須の変数は、pkgname
、pkgver
、pkgrel
、および arch
です。 license
は、パッケージをビルドするために厳密に必要というわけではありませんが、makepkg が存在しない場合に警告を生成するため、他のユーザーと共有する PKGBUILD
には推奨されます。
ここで指定された順番で PKGBUILD
の変数を定義するのが一般的なやり方です。しかし、正しい Bash 構文が使われている限り、これは必須ではありません。
パッケージ名
pkgbase
通常のパッケージをビルドするときは、この変数を PKGBUILD
で明示的に宣言してはいけません:
この変数のデフォルトの値は pkgname の値です。
分割パッケージ をビルドするときは、この変数を使って makepkg の出力やソースだけの tarball の名前付けにパッケージのグループを参照するために使う名前を明示的に指定できます。この値はハイフンで始めることはできません。指定しない場合、値はデフォルトで pkgname
配列の最初の要素になります。
分割パッケージのすべてのオプションとディレクティブのデフォルトは PKGBUILD
で指定されたグローバルな値です。ただし、以下のものは各分割パッケージのパッケージング関数の中でオーバーライドすることができます。pkgdesc, arch, url, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options, install そして changelog
pkgname
パッケージの名前、例えば pkgname='foo'
か、分割パッケージの場合は名前の配列、例えば pkgname=('foo' 'bar')
を指定します。パッケージ名は小文字の英数字と以下の文字のみで構成されている必要があります。@._+-
は小文字の英数字と以下の文字で構成されています。(アットマーク、ドット、アンダースコア、プラス、ハイフン) ハイフンやドットで名前を始めることはできません。一貫性を保つために、pkgname
はソフトウェアのソース tarball の名前と一致させるべきです。例えば、ソフトウェアが foobar-2.5.tar.gz
に入っているならば、pkgname=foobar
と記述して下さい。
バージョン
pkgver
パッケージのバージョン。この値はパッケージの作成者によって公開されたバージョンと同じでなくてはなりません。文字と数字、ピリオドとアンダーバーを使えますがハイフンは使うことができません。パッケージの作成者がバージョンのナンバリングにハイフンを使っている時は、アンダーバーに置き換えてください。例えば、バージョンが 0.99-10 の場合、0.99_10 に変更してください。pkgver
を後で PKGBUILD で使うときに、ダッシュの代わりにアンダーラインを使うのは簡単にできます 例:
source=($pkgname-${pkgver//_/-}.tar.gz)
pkgrel
Arch Linux におけるパッケージのリリース番号。パッケージの同じバージョンを続けてビルドするときにそれを区別するためにこの値を使います。新しいバージョンのパッケージが始めてリリースされたとき、リリース番号は1からスタートします。PKGBUILD
ファイルに修正や最適化が加えられるたびに、パッケージは再リリースされリリース番号は1づつ増やされます。新しいバージョンのパッケージが出たら、リリース番号は1にリセットします。
epoch
バージョン番号が更新を引き起こさないときでも、(epoch が低い) 以前のバージョンよりもパッケージを新しいものだと強制的に見せるために使用されます。この変数の値は正の整数でなくてはなりません。指定されていない場合、デフォルトの値は 0 になります。パッケージのナンバリングの規則が変更されたり、バージョンの通常の比較ルールを破壊したいときに有用です。例:
pkgver=5.13 pkgrel=2 epoch=1
1:5.13-2
バージョンの比較についての詳細は pacman(8) を見て下さい。
汎用
pkgdesc
パッケージの説明。これは 80 文字以下にすることをお勧めします。また、アプリケーション名がパッケージ名と異なる場合を除き、パッケージ名を自己参照的に含めないでください。たとえば、pkgdesc="Nedit is a text editor for X11"
の代わりに pkgdesc="Text editor for X11"
を使用します。
また、キーワードを賢く使用して、関連する検索クエリに表示される可能性を高めることも重要です。
arch
PKGBUILD
がビルド・動作するアーキテクチャの文字列。現在、i686
と x86_64
が使えます。ただし、Arch Linux ARM などのプロジェクトでは他のアーキテクチャもサポートしています: arm
(armv5), armv6h
(armv6 hardfloat), armv7h
(armv7 hardfloat), aarch64
(armv8 64bit)。
アーキテクチャに依存しないパッケージ (シェルスクリプト, フォント, テーマなど) には any
を使うことができます。-i686
や -x86_64
とは対照的に、一度ビルドしたら他のアーキテクチャでも使うことができるようなパッケージには -any
を指定してください。全てのアーキテクチャに対応するようにパッケージをコンパイルすることができても、特定のアーキテクチャに向けてコンパイルされる場合は、Arch によって公式にサポートされているアーキテクチャを指定してください: arch=('i686' 'x86_64')
。
$CARCH
変数を使うことで、ビルドや、変数を定義する時にターゲットとするアーキテクチャを知ることができます。FS#16352 を参照してください。例:
depends=(foobar) if test "$CARCH" == x86_64; then depends+=(lib32-glibc) fi
url
パッケージされるソフトウェアの公式サイトの URL。
license
ソフトウェアが配布されるライセンス。[core]
の licenses パッケージは /usr/share/licenses/common
によく使われるライセンスを保存しています、例えば /usr/share/licenses/common/GPL
パッケージのライセンスがここに保存されているライセンスのどれかのときは、ディレクトリの名前を設定してください、例えば license=('GPL')
適切なライセンスが公式の licenses パッケージに含まれていない場合は、やる必要があることがいくつかあります:
- ライセンスファイルを次のディレクトリに含めなくてはなりません:
/usr/share/licenses/pkgname/
, 例/usr/share/licenses/foobar/LICENSE
- ソース tarball にライセンスの詳細が含まれずウェブサイトなど他のところで示されている場合は、ライセンスをファイルにコピーしてそのファイルを含めて下さい。
license
行にcustom
を追加してください。任意で、custom
をcustom:ライセンスの名前
にすることができます。あるライセンスが ([community] を含む
) 公式リポジトリの2つ以上のパッケージで使われると、licenses パッケージに入れられます。
- 特別な事例として BSD, MIT, zlib/png, Python ライセンスは licenses パッケージに含められていません。
license
行の目的のために、一般的なライセンス (license=('BSD')
,license=('MIT')
,license=('ZLIB')
,license=('Python')
) として扱われておきながらそれぞれ固有の copyright 行を持っているために技術的にカスタムライセンスになっています。これら4つのライセンスを使っている全てのパッケージは/usr/share/licenses/pkgname
内にそのライセンスを保存しておく必要があります。パッケージによってはライセンスがひとつだけではないこともあります。そのような場合は、license 行に複数のエントリを書くことができます、例えばlicense=('GPL' 'custom:name of license')
- さらに、(L)GPL には多くのバージョンと組み合わせが存在します。(L)GPL ソフトウェアで使えるのは:
- (L)GPL - (L)GPLv2 とそれ以降のバージョン
- (L)GPL2 - (L)GPL2 のみ
- (L)GPL3 - (L)GPL3 とそれ以降のバージョン
- license が決められていないと、
PKGBUILD.proto
はunknown
を使うことを提案します。ただし、ソフトウェアが利用できるかできないかについてはアップストリームに連絡をすべきです。
こちらも参照 ノンフリーアプリケーションパッケージガイドライン
フリーおよびオープン ソース ソフトウェア ライセンスに関する追加情報と展望は、次のページで見つけることができます。
- 自由ソフトウェアライセンス
- Wikipedia:Comparison of free and open-source software licenses
- オープン ソースおよびフリー ソフトウェア プロジェクトの法的問題の入門書
- GNU Project - さまざまなライセンスとそれらについての解説
- Debian - ライセンス情報
- Open Source Initiative - 名前別ライセンス
groups
パッケージが属する group たとえば、plasma をインストールすると、そのグループに属するすべてのパッケージがインストールされます。
依存関係
depends
ソフトウェアを実行する前にインストールする必要があるパッケージの名前を示す文字列。ソフトウェアが依存パッケージの最低必要バージョンがあるときは、>=
演算子を使ってこれを表して下さい、例 depends=('foobar>=1.8.0')
。あなたのソフトウェアが依存している他のパッケージの依存にすでに含まれているパッケージを depends に加える必要はありません。例えば、gtk2 は glib2 と glibc に依存しています。しかしながら、glibc は glib2 の依存にあるので gtk2 の依存として glibc を含める必要はありません。
optdepends
ソフトウェアを機能させるのには必要ないが機能を追加することができるパッケージの名前の文字列。それぞれのパッケージが提供する機能の説明も短く書いておいて下さい。例えば optdepends
は以下のようになります:
optdepends=('cups: printing support' 'sane: scanners support' 'libgphoto2: digital cameras support' 'alsa-lib: sound support' 'giflib: GIF images support' 'libjpeg: JPEG images support' 'libpng: PNG images support')
makedepends
ソフトウェアをビルドするためにインストールする必要はあるが、インストール後にソフトウェアを使うために残しておく必要はないパッケージの名前。depends
行と同じフォーマットを使ってパッケージの最小必要バージョンを指定できます。
checkdepends
テストスイートを実行するときに必要だが普通の実行時には必要ないパッケージの文字列。このリストのパッケージは depends と同じフォーマットに従います。check() 関数が makepkg によって実行される時だけこの依存関係が考慮されます。
パッケージの関係性
provides
パッケージの機能を提供するパッケージ (もしくは cron
や sh
などの仮想パッケージ) の名前の文字列。同じものを提供するパッケージは互いに衝突しないかぎり同時にインストールすることができます。
conflicts
インストールするとパッケージと問題が生じるパッケージの名前の文字列。この名前を持つパッケージとこの名前の仮想パッケージを provides
に入れている全てのパッケージが削除されます。depends
行と同じフォーマットを使って衝突するパッケージのバージョンプロパティを指定することもできます。
競合は、pkgname
および provides
配列で指定された名前に対してチェックされることに注意してください。したがって、パッケージが provides
に foo
機能を備えている場合、conflicts
配列に foo
を指定すると、あなたのパッケージと、provides
配列に foo
を含む他のすべてのパッケージとの間の競合 (つまり、競合するすべてのパッケージ名を flicts
配列に指定する必要はありません) 具体的な例を挙げてみましょう。
- netbeans は暗黙的に
netbeans
をpkgname
自身として提供しています。 - netbeans-cppAUR は
netbeans
を提供し、netbeans
と衝突します。 - netbeans-phpAUR は
netbeans
を提供し、netbeans
と衝突しますが、同じ機能を提供するパッケージは暗黙のうちに衝突するので、明示的に netbeans-cppAUR と衝突する必要はありません。
パッケージが provides
配列を介して同じ機能を提供する場合、代替パッケージを conflicts
配列に明示的に追加する場合と追加しない場合には違いがあります。conflicts
配列が明示的に宣言されている場合、同じ機能を提供する 2 つのパッケージが 代替 とみなされます。conflicts
配列が欠落している場合、同じ機能を提供する 2 つのパッケージが 共存している可能性がある とみなされます。パッケージャは、conflicts
変数を宣言するかどうかを決定する際に、provides
変数の内容を常に無視する必要があります。
replaces
例えば wireshark-qt は replaces=('wireshark')
を使います。同期する時、pacman はインストールされたパッケージがリポジトリで replaces
にマッチする別のパッケージに出会ったら即座に置き換えます。既にあるパッケージの別バージョンを提供したり AUR にアップロードする時は conflicts
と provides
配列を使ってください。
その他
backup
ユーザーが作成した変更を含んだり、パッケージのアップグレードや削除が行われても維持されるファイルの文字列、主に /etc
内の設定ファイル用。
アップデート時、既存のファイル(ユーザーによって修正されたファイル)を上書きしないために新しいバージョンは file.pacnew
として保存されます。同じく、パッケージの削除時、パッケージを削除するのに pacman -Rn
コマンドを使わなければ、ユーザーが修正したファイルは file.pacsave
として残されます。
この行のファイルパスは絶対パス (例: /etc/pacman.conf
) ではなく相対パス (例: etc/pacman.conf
) にしてください。Pacnew と Pacsave ファイルも参照。
options
この文字列を使うと /etc/makepkg.conf
で定義された makepkg
のデフォルトの挙動の一部を上書きできます。オプションをセットするには、文字列にオプションの名前を入れて下さい。デフォルトの挙動を逆にするには、オプションの前に !
を付けて下さい。options には以下のオプションを置くことが可能です:
strip
- バイナリとライブラリからシンボルを除去。プログラムやライブラリでデバッガを頻繁に使う時は、このオプションを無効にすると便利です。docs
-/doc
ディレクトリを保存。libtool
- パッケージに libtool (.la
) ファイルを残す。staticlibs
- パッケージに静的ライブラリ (.a) のファイルを残す。emptydirs
- パッケージに空のディレクトリを残す。zipman
- man と info ページを gzip で圧縮。purge
- パッケージのPURGE_TARGETS
変数で指定されたファイルを削除。upx
- UPX を使って実行可能バイナリを圧縮。UPXFLAGS
変数を指定することで UPX に追加オプションを渡せます。ccache
- ビルド中のccache
の使用を許可。ccache
を使ってビルドすると問題が起こるパッケージに無効化の!ccache
を使うと便利です。distcc
- ビルド中のdistcc
の使用を許可。distcc
を使ってビルドすると問題が起こるパッケージに無効化の!distcc
を使うと便利です。buildflags
- ビルド中にユーザー定義のbuildflags
(CFLAGS, CXXFLAGS, LDFLAGS) の使用を許可。カスタムしたbuildflags
を使ってビルドすると問題が起こるパッケージに無効化の!buildflags
を使うと便利です。makeflags
- ビルド中にユーザー定義のmakeflags
の使用を許可。カスタムしたmakeflags
を使ってビルドすると問題が起こるパッケージに無効化の!makeflags
を使うと便利です。
install
パッケージに含まれる .install
スクリプトの名前。pkgname
と同じ名前にしてください。パッケージのインストール・削除・アップグレードの際に、pacman はパッケージごとにスクリプトを保存・実行する機能があります。スクリプトには、実行される段階によって以下の関数を含めることができます:
pre_install
- ファイルが展開される前にスクリプトを実行。1つの引数が渡されます: 新しいパッケージのバージョン。post_install
- ファイルが展開された後にスクリプトを実行。1つの引数が渡されます: 新しいパッケージのバージョン。pre_upgrade
- ファイルが展開される前にスクリプトを実行。2つの引数が渡されます: 新しいパッケージのバージョン, 古いパッケージのバージョン。post_upgrade
- ファイルが展開された後にスクリプトを実行。2つの引数が渡されます: 新しいパッケージのバージョン, 古いパッケージのバージョン。pre_remove
- ファイルが削除される前にスクリプトを実行。1つの引数が渡されます: 古いパッケージのバージョン。post_remove
- ファイルが削除された後にスクリプトを実行。1つの引数が渡されます: 古いパッケージのバージョン。
それぞれの関数は pacman のインストールディレクトリの中に chroot されて実行されます。このスレッド を見て下さい。
changelog
パッケージの変更履歴の名前。インストールされたパッケージの変更履歴を表示するには:
$ pacman -Qc pkgname
ソース
source
パッケージをビルドするのに必要なファイルの文字列。ソフトウェアのソースの場所を入れる必要があり、多くの場合 HTTP や FTP の URL です。前に設定した pkgname
や pkgver
変数をここで使うことができます (例: source=(http://example.com/$pkgname-$pkgver.tar.gz)
)。
自作のパッチなど、オンザフライでダウンロードできないファイルを供給する必要があるときは、PKGBUILD
ファイルがあるところと同じディレクトリにそのファイルを入れて source にファイル名を追加するだけです。ここに追加したパスはすべて PKGBUILD
があるディレクトリから相対的に考えられます。本当のビルドプロセスが始まる前に、この行で参照されている全てのファイルがダウンロードされるか存在を確認します。もしファイルが欠けている場合は makepkg
は次に進みません。
拡張子が .sig, .sign, .asc のファイルを source 配列に指定した場合、makepkg はそれを PGP 署名として認識して、ソースファイルの整合性を確認するのに自動的に用います。
noextract
source
行で makepkg
によって圧縮フォーマットを展開してはいけないファイルの文字列。libarchive は unzip とは違い全てのファイルをランダムアクセスではなくストリームで処理するので、/usr/bin/bsdtar
によって扱えない圧縮ファイルに noextract を使うのがほとんどです。こういった場合には他の解凍ツール (例: unzip
, p7zip
など) を makedepends
に追加して prepare() 関数の最初の行でソースの圧縮ファイルを手動で展開する必要があります。例えば:
prepare() { lrzip -d source.tar.lrz }
source
行には URL を指定することが可能ですが、noextract
にはファイル名の一部だけを指定します。例えば、以下のようにすることができます (grub2 の PKGBUILD から引用):
source=("http://ftp.archlinux.org/other/grub2/grub2_extras_lua_r20.tar.xz") noextract=("grub2_extras_lua_r20.tar.xz")
何も展開しないようにするには、以下のように工夫してください (firefox-i18n から引用):
noextract=(${source[@]%%::*})
validpgpkeys
PGP フィンガープリントの配列。validpgpkeys を使用した場合、makepkg は validpgpkeys に記載されている鍵の署名だけを使うようにして鍵束の値は無視します。ソースファイルが副鍵で署名されていた場合、makepkg は主鍵を使って比較します。
指定できるのは完全なフィンガープリントだけです。全て大文字で空白を含めてはいけません。
整合性
以下の変数はどれもチェックサム文字列を指定するようになっており、source 配列に書かれたファイルの整合性を確認するのに使われます。SKIP
とすることで特定のファイルのチェックサムを確認しないようにできます。
チェックサムの種類と値は、リリースアナウンスなど上流から提供されたものを常に使用する必要があります。複数のタイプが利用可能な場合は、最も強力なチェックサムが優先されます。sha512
よりも b2
, sha384
よりも sha384
, sha256
よりも sha512
を優先してください, sha224
に対して sha256
、sha1
に対して sha224
、md5
に対して sha1
、および md5
以上 ck
} があります。これは、上流のアナウンスからパッケージのビルドまで、ダウンロードしたファイルの完全性を保証するために最適な方法です。
これらの変数の値は makepkg の -g
/--geninteg
オプションで自動生成され、一般に makepkg -g >> PKGBUILD
で追加されます。pacman-contrib の updpkgsums(8) コマンドは PKGBUILD
内のどこにあっても変数を更新することが可能です。どちらのツールも PKGBUILD
に既に設定されている変数を使い、設定されていない場合は md5sums
にフォールバックします。
使用するファイルの整合性チェックは /etc/makepkg.conf
の INTEGRITY_CHECK
オプションで設定することができます。 makepkg.conf(5) を参照してください。
cksums
source
配列にリストされているファイルの CRC32 チェックサム (UNIX 標準 cksum より)
md5sums
source
行に含まれるファイルの 128 ビット MD5 チェックサムの文字列。
sha1sums
source
行に含まれるファイルの 160ビットの SHA-1 チェックサムの文字列。
sha256sums
ダイジェスト サイズが 256 ビットの SHA-2 チェックサムの配列。
sha224sums, sha384sums, sha512sums
それぞれ 224, 384, 512 ビットのダイジェストサイズの SHA-2 チェックサムの文字列。sha256sums
の代替ですが、あまり一般的ではない代替手段です。
b2sums
BLAKE2 チェックサムの配列で、ダイジェスト サイズは 512 ビットです。