「PKGBUILD」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(Pkg/AUR テンプレートの更新)
(→‎整合性: 情報を更新)
251行目: 251行目:
 
以下の変数はどれもチェックサム文字列を指定するようになっており、[[#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ビットのダイジェストサイズ。
 +
ダイジェスト サイズが 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}} の代替ですが、あまり一般的ではない代替手段です。
   
 
== 参照 ==
  
== 参照 ==

2022年12月20日 (火) 04:02時点における版

関連記事

PKGBUILD はパッケージを作成するときに使われる Arch Linux のパッケージビルド記述ファイルです (中身はシェルスクリプトです)。

Arch Linux では makepkg ユーティリティと PKGBUILD 内の情報を使ってパッケージがビルドされます。makepkg が実行されると、作業ディレクトリ内で PKGBUILD が検索されその中の記述に従ってコンパイルしたりファイルを取得してパッケージファイル (pkgname.pkg.tar.xz) が作成されます。作られたパッケージにはバイナリファイルとインストールの記述が含まれており、pacman によって読み込まれインストールされます。

この記事では PKGBUILD で使用する変数について扱っています。PKGBUILD の関数についての情報は、パッケージの作成#PKGBUILD の関数を参照してください。

ヒント: パッケージを作成するときのよくある間違いが PKGBUILD にないかを namcap でチェックできます。

変数

PKGBUILD ファイルの中で使うことができる変数は以下の通りです。

pkgname, pkgver, pkgrel, arch は全て必須です。license はパッケージのビルドには必須ではありませんが、他の人と共有したい PKGBUILD には含めるのが推奨されています。存在しない場合 makepkg は警告を表示します。

PKGBUILD 内では変数をこのページと同じ順番で定義するのが通例となっています。ただし、それは必須ではなく、Bash の構文が正しければ問題ありません。

パッケージ名

pkgbase

分割パッケージを作成するときに使うことができる、任意のグローバルディレクティブ。pkgbase を使うことで makepkg の出力とソース tarball の名でパッケージのグループを参照することができます。pkgbase が指定されていない場合、pkgname 変数の最初のエレメントが使われます。この変数の先頭の文字をハイフンにすることはできません。分割パッケージの全ての値はデフォルトで PKGBUILD に指定されたグローバルな値になります。#makedepends, #ソース, #整合性 の変数を除く、全ての変数を分割パッケージの package() 関数で上書きすることができます。

pkgname

パッケージの名前。含めることができる文字は、小文字の英数字と以下の記号です: @, ., _, +, - (アットマーク、ドット、アンダーバー、プラス、ハイフン)。全ての文字は小文字でなくてはならず名前の最初をハイフンにすることはできません。一貫性を保つために、pkgname はパッケージするソース tarball の名前と一致させてください。例えば、ソフトウェアが foobar-2.5.tar.gz なら、pkgname の値は foobar にするべきです。PKGBUILD ファイルを入れる作業ディレクトリも pkgname と一致させる必要があります。

分割パッケージは配列として定義します。例: pkgname=('foo' 'bar')。

バージョン

pkgver

パッケージのバージョン。この値はパッケージの作成者によって公開されたバージョンと同じでなくてはなりません。文字と数字、ピリオドとアンダーバーを使えますがハイフンは使うことができません。パッケージの作成者がバージョンのナンバリングにハイフンを使っている時は、アンダーバーに置き換えてください。例えば、バージョンが 0.99-10 の場合、0.99_10 に変更してください。pkgver を後で PKGBUILD で使うときに、ダッシュの代わりにアンダーラインを使うのは簡単にできます 例: 

source=($pkgname-${pkgver//_/-}.tar.gz)
ノート: ソフトウェアの開発元が 30102014 のようなタイムスタンプによるバージョン付けをしている場合、日付の順序を逆にしてください: 20141030 (ISO 8601 形式)。そうしないと新しいバージョンが認識されません。
ヒント:

pkgrel

Arch Linux におけるパッケージのリリース番号。パッケージの同じバージョンを続けてビルドするときにそれを区別するためにこの値を使います。新しいバージョンのパッケージが始めてリリースされたとき、リリース番号は1からスタートします。PKGBUILD ファイルに修正や最適化が加えられるたびに、パッケージは再リリースされリリース番号は１づつ増やされます。新しいバージョンのパッケージが出たら、リリース番号は1にリセットします。

epoch

警告: epoch はどうしても必要なときだけ使って下さい。

バージョン番号が更新を引き起こさないときでも、(epoch が低い) 以前のバージョンよりもパッケージを新しいものだと強制的に見せるために使用されます。この変数の値は正の整数でなくてはなりません。指定されていない場合、デフォルトの値は 0 になります。パッケージのナンバリングの規則が変更されたり、バージョンの通常の比較ルールを破壊したいときに有用です。例: 

pkgver=5.13
pkgrel=2
epoch=1
1:5.13-2

バージョンの比較についての詳細は pacman(8) を見て下さい。

汎用

pkgdesc

パッケージの説明。説明は80文字以下でなくてはならず、また説明の中にパッケージ名を含めて自己参照してはいけません。例えば、"Nedit is a text editor for X11" は "A text editor for X11" に書き換えてください。

ノート: AUR にパッケージを投稿するときは、このルールにむやみに従ってはいけません。何らかの理由でパッケージの名前がアプリケーションの名前と異なる場合、検索でパッケージを表示する唯一の方法はフルネームを説明に入れることです。

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 パッケージに含まれていない場合は、やる必要があることがいくつかあります:

  1. ライセンスファイルを次のディレクトリに含めなくてはなりません: /usr/share/licenses/pkgname/, 例 /usr/share/licenses/foobar/LICENSE。
  2. ソース tarball にライセンスの詳細が含まれずウェブサイトなど他のところで示されている場合は、ライセンスをファイルにコピーしてそのファイルを含めて下さい。
  3. license 行に custom を追加してください。任意で、custom を custom:ライセンスの名前 にすることができます。あるライセンスが ([community] を含む) 公式リポジトリの２つ以上のパッケージで使われると、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 を使うことを提案します。ただし、ソフトウェアが利用できるかできないかについてはアップストリームに連絡をすべきです。
ヒント: ソフトウェアの作者によってはライセンスファイルを作らずに普通の ReadMe.txt の中に配布ルールについて記述しているかもしれません。build() フェイズの時に、次のようにすることでファイルにこの情報を展開することが可能です: sed -n '/This software/,/ thereof./p' ReadMe.txt > LICENSE。

groups

パッケージが属するグループ。例えば、kdebase[リンク切れ: パッケージが存在しません] パッケージをインストールすると、kde[リンク切れ: パッケージが存在しません] グループに含まれる全てのパッケージをインストールします。

依存関係

ノート: アンダーバーとアーキテクチャの名前を付けることで、特定のアーキテクチャだけの依存パッケージを追加することができます。例: depends_x86_64=(), optdepends_x86_64=()。

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 行と同じフォーマットを使ってパッケージの最小必要バージョンを指定できます。

ノート: 既に depends に含まれているパッケージを指定する必要はありません。
警告: makepkg でビルドする際 base-devel グループは既にインストールされているものと前提されます。"base-devel" のパッケージを makedepends 行に入れてはいけません。

checkdepends

テストスイートを実行するときに必要だが普通の実行時には必要ないパッケージの文字列。このリストのパッケージは depends と同じフォーマットに従います。check() 関数が makepkg によって実行される時だけこの依存関係が考慮されます。

パッケージの関係性

ノート: アンダーバーとアーキテクチャの名前を付けることで、特定のアーキテクチャだけのパッケージの関係性を追加することができます。例: provides_x86_64=(), conflicts_x86_64=()。

provides

パッケージの機能を提供するパッケージ (もしくは cron や sh などの仮想パッケージ) の名前の文字列。同じものを提供するパッケージは互いに衝突しないかぎり同時にインストールすることができます（下を見て下さい）。この変数を使う場合は、バージョンによって影響を受ける依存関係がある場合パッケージが提供するバージョン (pkgver と恐らく pkgrel) を追加してください。例えば、qt にモディファイを加えて qt を提供する　qt-foobar バージョン 3.3.8 という名前で作成するときは、provides 行は provides=('qt=3.3.8') のようにしてください。provides=('qt') とすると qt の特定バージョンを必要とする依存関係が破壊されることになります。provides 行に pkgname を加えないでください、自動で追加されます。

conflicts

インストールするとパッケージと問題が生じるパッケージの名前の文字列。この名前を持つパッケージとこの名前の仮想パッケージを provides に入れている全てのパッケージが削除されます。depends 行と同じフォーマットを使って衝突するパッケージのバージョンプロパティを指定することもできます。

replaces

パッケージによって置き換えられる廃止パッケージの名前の文字列、例えば wireshark[リンク切れ: 置換パッケージ: wireshark-qt] パッケージには replaces=('ethereal')。pacman -Sy で同期をした後、リポジトリ内の replaces に一致する他のパッケージが現れるとインストールされたパッケージを置き換えます。既存のパッケージの別バージョンを提供するときは、衝突するパッケージをインストールするときに評価される conflicts 変数を使って下さい。

その他

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 されて実行されます。このスレッド を見て下さい。

ヒント: .install のプロトタイプが /usr/share/pacman/proto.install にあります。
ノート: スクリプトの中で exit を実行しないでください。スクリプト内の関数が実行できなくなってしまいます。

changelog

パッケージの変更履歴の名前。インストールされたパッケージの変更履歴を表示するには: 

$ pacman -Qc pkgname
ヒント: 変更履歴ファイルのプロトタイプが /usr/share/pacman/ChangeLog.proto にあります。

ソース

ノート: アンダーバーとアーキテクチャの名前を追加することで特定のアーキテクチャのソースを追加することができます。例: source_x86_64=()。そのアーキテクチャのソースと対応するチェックサムも指定してください。例: sha256sums_x86_64=()。

source

パッケージをビルドするのに必要なファイルの文字列。ソフトウェアのソースの場所を入れる必要があり、多くの場合 HTTP や FTP の URL です。前に設定した pkgname や pkgver 変数をここで使うことができます (例: source=(http://example.com/$pkgname-$pkgver.tar.gz))。

自作のパッチなど、オンザフライでダウンロードできないファイルを供給する必要があるときは、PKGBUILD ファイルがあるところと同じディレクトリにそのファイルを入れて source にファイル名を追加するだけです。ここに追加したパスはすべて PKGBUILD があるディレクトリから相対的に考えられます。本当のビルドプロセスが始まる前に、この行で参照されている全てのファイルがダウンロードされるか存在を確認します。もしファイルが欠けている場合は makepkg は次に進みません。

ヒント: ダウンロードされるファイルに異なる名前を指定するには - GET パラメータがある URL などが原因でダウンロードされるファイルの名前が異なる場合 - 次の構文を使って下さい: filename::fileuri, 例えば: source=("project_name::hg+https://googlefontdirectory.googlecode.com/hg/"。
ノート: .install ファイルは source に記述してはいけません。

拡張子が .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 は主鍵を使って比較します。

指定できるのは完全なフィンガープリントだけです。全て大文字で空白を含めてはいけません。

ノート: gpg --list-keys --fingerprint <KEYID> で指定した鍵のフィンガープリントを確認できます。

整合性

以下の変数はどれもチェックサム文字列を指定するようになっており、source 配列に書かれたファイルの整合性を確認するのに使われます。SKIP とすることで特定のファイルのチェックサムを確認しないようにできます。

チェックサムの種類と値は、リリースアナウンスなど上流から提供されたものを常に使用する必要があります。複数のタイプが利用可能な場合は、最も強力なチェックサムが優先されます。sha512 よりも b2, sha384 よりも sha384, sha256 よりも sha512 を優先してください, sha224 に対して sha256、sha1 に対して sha224、md5 に対して sha1、および { {ic|md5}} 以上 ck} があります。これは、上流のアナウンスからパッケージのビルドまで、ダウンロードしたファイルの完全性を保証するために最適な方法です。

ノート: さらに、上流が デジタル署名 を利用可能にしたら、署名ファイルを source 配列に、PGP 鍵指紋を validpgpkeys 配列に追加する必要があります。これにより、ビルド時にファイルの認証ができるようになります。

これらの変数の値は makepkg の -g/--geninteg オプションで自動生成され、一般に makepkg -g >> PKGBUILD で追加されます。pacman-contrib の updpkgsums(8) コマンドは PKGBUILD 内のどこにあっても変数を更新することが可能です。どちらのツールも PKGBUILD に既に設定されている変数を使い、設定されていない場合は md5sums にフォールバックします。

使用するファイルの整合性チェックは /etc/makepkg.conf の INTEGRITY_CHECK オプションで設定することができます。 makepkg.conf(5) を参照してください。

ノート: 追加のアーキテクチャ固有の配列は、アンダースコアとアーキテクチャ名を付加することで追加できます、例えば sha256sums_x86_64=()

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 の代替ですが、あまり一般的ではない代替手段です。

参照

「https://wiki.archlinux.jp/index.php?title=PKGBUILD&oldid=28892」から取得