「Makepkg」の版間の差分
(→署名チェック: 情報を更新) |
(→使用方法: 情報を更新) |
||
70行目: | 70行目: | ||
== 使用方法 == |
== 使用方法 == |
||
− | + | 続行する前に、{{Grp|base-devel}} グループを [[インストール]] してください。このグループに属するパッケージは、[[PKGBUILD]] ファイルでビルド時の依存関係 (''makedepends'') としてリストする必要はありません。 |
|
+ | {{Note|1=<nowiki></nowiki> |
||
− | # pacman -S base-devel |
||
+ | * [[pacman]] に渡されるコマンドに対して [[sudo]] が適切に設定されていることを確認してください。 |
||
+ | * ''makepkg'' 自体を root として実行することは [https://lists.archlinux.org/archives/list/pacman-dev@lists.archlinux.org/message/ZLRXMUGXULDHLTGSRYVGVWG3BVATV3OY/ 許可されていません].[https://gitlab.archlinux.org/pacman/pacman/blob/master/NEWS] {{ic|PKGBUILD}} に任意のコマンドが含まれる可能性があることに加えて、root としてビルドすることは一般的に安全ではないと考えられています。[https://bbs.archlinux.org/viewtopic.php?id=67561] 通常のユーザー アカウントにアクセスできないユーザーは、[http://allanmcrae.com/2015/01/replacing-makepkg-asroot/ nobody user] として makepkg を実行する必要があります。 |
||
+ | }} |
||
+ | パッケージをビルドするには、[[パッケージの作成]] で説明されているように、まず [[PKGBUILD]] またはビルド スクリプトを作成する必要があります。既存のスクリプトは、[[Arch Build System]] ''(ABS)'' ツリーまたは [[AUR]] から入手できます。 {{ic|PKGBUILD}} を取得したら、それが保存されているディレクトリに移動し、次のコマンドを実行してパッケージをビルドします。 |
||
− | {{Note|依存パッケージが欠けていることに不満を言う前に、全ての Arch Linux 環境では {{Pkg|base}} グループがインストールされていることが前提になっていることを思い出してください。'''makepkg''' や [[AUR ヘルパー]]でビルドするときには {{Grp|base-devel}} グループがインストールされていることが前提になっています。}} |
||
− | |||
− | パッケージを作成するには、まず[[パッケージの作成]]に記述されているようにして [[PKGBUILD]] を作成するか [[Arch Build System|ABS ツリー]]や [[Arch User Repository]] などから取得してくる必要があります。 |
||
− | |||
− | {{Warning|信頼できるソースからパッケージをビルド・インストールしてください。}} |
||
− | |||
− | {{ic|PKGBUILD}} を入手したら、PKGBUILD が保存されているディレクトリに移動してから次のコマンドを実行してパッケージを作成します: |
||
$ makepkg |
$ makepkg |
||
+ | 必要な依存関係が欠落している場合、''makepkg'' は失敗する前に警告を発します。パッケージをビルドして必要な依存関係をインストールするには、フラグ {{ic|-s}}/{{ic|--syncdeps}} を追加します。 |
||
− | パッケージ作成後、要らなくなったファイル ($srcdir に展開されたファイルなど) を makepkg によって削除するには、以下のオプションを加えて下さい。同じパッケージをビルドしたりパッケージのバージョンを更新するときに、同じビルドフォルダを使う場合、このオプションは有益です。残ったファイルを新しいビルドに持ち越す危険がなくなります。 |
||
− | $ makepkg - |
+ | $ makepkg --syncdeps |
+ | {{ic|-r}}/{{ic|--rmdeps}} フラグを追加すると、''makepkg'' は後で不要になった make 依存関係を削除します。常にパッケージをビルドしている場合は、[[Pacman ヒント#使用していないパッケージの削除 (孤立したパッケージ)]] を時々使用することを検討してください。 |
||
− | 必要な依存パッケージが欠けている場合、makepkg は警告を表示します。必要な依存パッケージを自動的にインストールするには、{{ic|--syncdeps}} あるいは {{ic|-s}} オプションを付けて実行します: |
||
− | |||
− | $ makepkg --syncdeps |
||
+ | {{Note| |
||
− | 依存パッケージが取ってこれるのは設定されたリポジトリからだけということに注意してください; 詳しくは [[pacman#リポジトリ]] を見て下さい。また、ビルドの前に手動で依存パッケージをインストールすることもできます ({{ic|pacman -S --asdeps dep1 dep2}})。 |
||
+ | * これらの依存関係は、構成されたリポジトリで利用可能である必要があります。詳細は [[pacman#リポジトリとミラー]] を参照してください。または、ビルドの前に依存関係を手動でインストールすることもできます ({{ic|pacman -S --asdeps ''dep1'' ''dep2''}}) |
||
+ | * 依存関係をインストールするときは、グローバル値のみが使用されます。つまり、分割パッケージのパッケージング関数で行われたオーバーライドは使用されません。 |
||
+ | }} |
||
+ | すべての依存関係が満たされ、パッケージが正常にビルドされると、パッケージファイル ({{ic|''pkgname''-''pkgver''.pkg.tar.zst}}) が作業ディレクトリに作成されます。インストールするには、{{ic|-i}}/{{ic|--install}} を使用します ({{ic|pacman -U ''pkgname''-''pkgver''.pkg.tar.zst}}): |
||
− | なお、{{ic|-r}} または {{ic|--rmdeps}} オプションを付けると ''makepkg'' はビルド後に必要のない依存関係を削除します。しかし今後もビルドを継続的に行なうなら時々 [[Pacman ヒント#使用していないパッケージの削除 (孤立したパッケージ)]] を行うほうが望ましいです。 |
||
+ | $ makepkg --install |
||
− | 全ての依存関係が解決されパッケージのビルドが成功すれば、パッケージファイル ({{ic|pkgname-pkgver.pkg.tar.xz}}) が作業ディレクトリの中に作成されます。インストールするには、(root で) 次を実行してください: |
||
+ | {{ic|$srcdir}} に抽出されたファイルなど、残りのファイルとディレクトリをクリーンアップするには、オプション {{ic|-c}}/{{ic|--clean}} を追加します。これは、同じビルド ディレクトリを使用しながら、同じパッケージの複数のビルドやパッケージバージョンの更新に役立ちます。古いファイルや残りのファイルが新しいビルドに引き継がれるのを防ぎます。 |
||
− | # pacman -U pkgname-pkgver.pkg.tar.xz |
||
+ | $ makepkg --clean |
||
− | もしくは、{{ic|pacman -U pkgname-pkgver.pkg.tar.xz}} を実行する代わりに {{ic|-i}} フラグを使ってインストールすることもできます: |
||
+ | 詳細については、{{man|8|makepkg}} を参照してください。 |
||
− | $ makepkg -i |
||
== ヒントとテクニック == |
== ヒントとテクニック == |
2023年1月28日 (土) 20:07時点における版
makepkg はパッケージのビルドを自動化するスクリプトです。makepkg スクリプトを使用するにはビルドが出来る Unix プラットフォームと PKGBUILD が必要です。
makepkg は pacman パッケージの中に入っています。
目次
- 1 設定
- 2 使用方法
- 3 ヒントとテクニック
- 4 トラブルシューティング
- 5 参照
設定
makepkg の設定オプションについて詳しくは makepkg.conf(5) を参照してください。
/etc/makepkg.conf
が makepkg のメインの設定ファイルです。ユーザー個別の設定は $XDG_CONFIG_HOME/pacman/makepkg.conf
または ~/.makepkg.conf
で可能です。パッケージをビルドする前に makepkg の設定オプションを微調整するとよいでしょう。
パッケージ作成者の情報
パッケージにはメタデータが付与されておりパッケージ作成者を識別することができます。デフォルトでは、ユーザーがコンパイルしたパッケージは Unknown Packager
となります。システム上の複数のユーザーがパッケージをコンパイルする場合、あるいはパッケージを他者に配布する場合、実際の連絡先を入力すると便利です。makepkg.conf
の PACKAGER
変数で設定することができます。
インストールしたパッケージの作成者情報を確認するには:
$ pacman -Qi package
[...] Packager : John Doe <john@doe.com> [...]
生成したパッケージに自動的に署名するには makepkg.conf
で GPGKEY
変数を設定してください。
パッケージの出力
デフォルトでは makepkg はパッケージ tarball を作業ディレクトリに作成し、ソースデータを src/
ディレクトリに直接ダウンロードします。カスタムパスを設定することで、例えばビルドしたパッケージを ~/build/packages/
に、ソースを全て ~/build/sources/
に保存することができます。
必要に応じて以下の makepkg.conf
変数を設定してください:
PKGDEST
— 生成したパッケージを保存するディレクトリ。SRCDEST
— ソースデータを保存するディレクトリ (別の場所を指定するとsrc/
へのシンボリックリンクが作成されます)。SRCPKGDEST
— 生成したソースパッケージを保存するディレクトリ (makepkg -S
でビルドされます)。
署名チェック
.sig または .asc の形式の署名ファイルが PKGBUILD ソース配列の一部である場合、makepkg は自動的に 検証 を試みます。ユーザーのキーリングに署名の検証に必要な公開鍵が含まれていない場合、makepkg は PGP 鍵を検証できなかったというメッセージを表示してインストールを中止します。
パッケージに必要な公開鍵が欠落している場合、PKGBUILD には必要な鍵 ID を持つ validpgpkeys エントリが含まれている可能性が高くなります。その場合手動で インポート 、または 鍵サーバー上 で見つけてそこからインポートします。署名チェックを一時的に無効にするには、--skippgpcheck
オプションを指定して makepkg を実行します。
使用方法
続行する前に、base-devel グループを インストール してください。このグループに属するパッケージは、PKGBUILD ファイルでビルド時の依存関係 (makedepends) としてリストする必要はありません。
パッケージをビルドするには、パッケージの作成 で説明されているように、まず PKGBUILD またはビルド スクリプトを作成する必要があります。既存のスクリプトは、Arch Build System (ABS) ツリーまたは AUR から入手できます。 PKGBUILD
を取得したら、それが保存されているディレクトリに移動し、次のコマンドを実行してパッケージをビルドします。
$ makepkg
必要な依存関係が欠落している場合、makepkg は失敗する前に警告を発します。パッケージをビルドして必要な依存関係をインストールするには、フラグ -s
/--syncdeps
を追加します。
$ makepkg --syncdeps
-r
/--rmdeps
フラグを追加すると、makepkg は後で不要になった make 依存関係を削除します。常にパッケージをビルドしている場合は、Pacman ヒント#使用していないパッケージの削除 (孤立したパッケージ) を時々使用することを検討してください。
すべての依存関係が満たされ、パッケージが正常にビルドされると、パッケージファイル (pkgname-pkgver.pkg.tar.zst
) が作業ディレクトリに作成されます。インストールするには、-i
/--install
を使用します (pacman -U pkgname-pkgver.pkg.tar.zst
):
$ makepkg --install
$srcdir
に抽出されたファイルなど、残りのファイルとディレクトリをクリーンアップするには、オプション -c
/--clean
を追加します。これは、同じビルド ディレクトリを使用しながら、同じパッケージの複数のビルドやパッケージバージョンの更新に役立ちます。古いファイルや残りのファイルが新しいビルドに引き継がれるのを防ぎます。
$ makepkg --clean
詳細については、makepkg(8) を参照してください。
ヒントとテクニック
ソースのダウンロードと抽出の時間を短縮する
特に VCSパッケージ をビルドするときに SRCDEST
を利用すると、以降のリビルドでソースの取得や展開にかかる時間を短縮できます。
最適化されたパッケージの作成
makepkg のデフォルトでは、様々なマシンでインストールできるような一般的なパッケージを生成するようにオプションが設定されています。ホストマシンにあわせてコンパイラの最適化を有効化することで、パッケージ化するソフトウェアの性能を向上させることができます。ただし特定のプロセッサアーキテクチャにあわせてパッケージをコンパイルした場合、他のマシンでは正しく動作しなくなります。x86_64 のマシンでは、時間を投資して公式のパッケージをリビルドすることでそれに見合うだけのパフォーマンスの向上を得られることは稀です。
標準外のコンパイラフラグを使うことでパフォーマンスが劣化する可能性も十分あります。ほとんどのコンパイラオプションは特定の状況でのみ有効であり、無差別に全てのパッケージに適用しないほうが良いでしょう。何かが速くなると確認・ベンチマークできない限り、無駄にコンパイラオプションを使わないことを推奨します。Gentoo の コンパイル最適化ガイド や 安全な CFLAGS 記事にはコンパイラの最適化に関する詳しい解説が載っています。
C/C++ コンパイラ (例: gcc や clang) に渡されるオプションは CFLAGS
, CXXFLAGS
, CPPFLAGS
環境変数で制御されます。同じように make ビルドシステムは MAKEFLAGS
を使います。Arch のビルドシステムでは makepkg.conf
の設定オプションとして makepkg はこれらの環境変数を使用します。デフォルト値は幅広いマシンにインストールできる汎用のパッケージを作成するように設定されています。
GCC はアーキテクチャ固有の最適化を自動で認識・有効化することができます。自動最適化を使用するには、-march
と -mtune
フラグを全て削除してから -march=native
を追加してください。例:
CFLAGS="-march=native -O2 -pipe -fstack-protector-strong" CXXFLAGS="${CFLAGS}"
march=native
フラグによってどのフラグが有効になるのか確認するには、次のコマンドを実行してください:
$ gcc -march=native -v -Q --help=target
特定のパッケージ作成者によるパッケージを表示
以下のコマンドはシステムにインストールされているパッケージの中から packagername という名前のパッケージ作成者によって作られたパッケージを全て表示します:
$ expac "%n %p" | grep "packagername" | column -t
以下のコマンドは /etc/makepkg
の PACKAGER
変数に設定されている値とパッケージ作成者が一致するパッケージを表示します (/etc/pacman.conf
に定義されているリポジトリに含まれているパッケージだけが対象):
$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)
コンパイル時間を短縮する
並列コンパイル
make ビルドシステムは、MAKEFLAGS
環境変数 を使用して、make の追加オプションを指定します。 変数は、 makepkg.conf
ファイルでも設定できます。
マルチコア/マルチプロセッサシステムを使用しているユーザーは、同時に実行するジョブの数を指定できます。 これは、 nproc を使用して使用可能なプロセッサの数を決定することで実現できます。 MAKEFLAGS="-j $(nproc)"
一部の PKGBUILD は、特定のバージョンの競合状態のため、または単に最初からサポートされていないため、これを -j1
で具体的にオーバーライドします。 このためにビルドに失敗したパッケージは、エラーが実際に発生していることを確認した後、バグトラッカー(またはAURパッケージの場合はパッケージメンテナ)に 報告 して下さい MAKEFLAGS
が原因です。
使用可能なオプションの完全なリストについては、 make(1) を参照してください。
メモリ内のファイルからビルドする
コンパイルには多くの I/O 操作と小さなファイルの処理が必要なため、作業ディレクトリを tmpfs に移動すると、ビルド時間が早くなる可能性があります。
BUILDDIR
変数を一時的に makepkg にエクスポートして、ビルドディレクトリを既存の tmpfs に設定できます。例えば:
$ BUILDDIR=/tmp/makepkg makepkg
永続的な設定は、デフォルトの /etc/makepkg.conf
ファイルの BUILDENVIRONMENT
セクションの最後にある BUILDDIR
オプションのコメントを外すことで行うことができます。この値をたとえば BUILDDIR=/tmp/makepkg
に設定すると、 Arch のデフォルトの /tmp
テンポラリ・ファイル・システムが使用されます。
ccache
ccache を使うことでコンパイル結果をキャッシュしてビルド時間を短縮できます。
新しいチェックサムを生成する
PKGBUILD ファイルが存在するディレクトリと同じディレクトリで以下のコマンドを実行すれば新しいチェックサムが生成されます:
$ updpkgsums
Windows の改行コード (\r\n
) に注意してください。Git はテキストファイルに含まれている Windows の改行コードを UNIX の改行コード \n
に置き換えるため、チェックサムが変わってしまいます。AUR のパッケージのチェックサムが検証できなかった場合、チェックサムを計算する前に以下のコマンドを使ってファイルの中から \r
を取り除いてみてください:
$ sed -i 's/\r//g' <filename>
他の圧縮アルゴリズムを使用する
パッケージ アーカイブが大きくなる代わりに、パッケージングとインストールの両方を高速化するには、PKGEXT
を変更します。
たとえば、次の例ではパッケージ ファイルの圧縮がスキップされ、インストール で展開する必要がなくなります。
$ PKGEXT='.pkg.tar' makepkg
別の例として、以下は速度に重点を置いた LZ4 アルゴリズムを使用しています。
$ PKGEXT='.pkg.tar.lz4' makepkg
上記の設定を永続化するには /etc/makepkg.conf
で PKGEXT
を設定します。
マルチコアを利用して圧縮する
zstd は、 --threads
フラグを介して 対称型マルチプロセッシング(SMP) をサポートし、圧縮を高速化します。たとえば、 makepkg がパッケージを圧縮するためにできるだけ多くの CPU コアを使用できるようにするには、/etc/makepkg.conf
の COMPRESSZST
配列を編集します:
COMPRESSZST=(zstd -c -z -q --threads=0 -)
xz は対称型マルチプロセッシング (SMP) による圧縮をサポートしています。--threads
フラグを使うことで圧縮が高速化されます。例えば、makepkg で出来る限り多くの CPU コアを使ってパッケージを圧縮するには、/etc/makepkg.conf
の COMPRESSXZ
配列を編集:
COMPRESSXZ=(xz -c -z --threads=0 -)
gzip の代替である並列実装の pigz はデフォルトで全ての CPU コアを使用します (-p/--processes
フラグを使うことでコアの数を減らせます。)
COMPRESSGZ=(pigz -c -f -n)
pbzip2は、 bzip2 のドロップイン並列実装であり、デフォルトで使用可能なすべての CPU コアも使用します。 -p#
フラグを使用すると、使用するコアの数を減らすことができます(注: -p
とコアの数の間にスペースは必要ありません。)
COMPRESSBZ2=(pbzip2 -c -f)
lbzip2 は、デフォルトで利用可能なすべての CPU コアを使用する bzip2 の別のドロップイン並列実装です。-n
フラグを使用すると、使用するコアを減らすことができます。
COMPRESSBZ2=(lbzip2 -c -f)
plzipAUR は lzip のマルチスレッド実装であり、デフォルトで利用可能なすべての CPU コアも使用します。-n
/--threads
フラグを使用して、使用するコアを減らすことができます。
COMPERSSLZ=(plzip -c -f)
64ビット環境で32ビットのパッケージをビルド
まず multilib リポジトリを有効にして multilib-devel をインストールしてください。gcc
や gcc-libs
パッケージを削除するかどうかきかれたら yes と答えてください。gcc-multilib は64ビットと32ビット両方のソフトウェアをビルドすることができます。
それから32ビットの設定ファイルを作成:
~/.makepkg.i686.conf
CARCH="i686" CHOST="i686-unknown-linux-gnu" CFLAGS="-m32 -march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong" CXXFLAGS="${CFLAGS}" LDFLAGS="-m32 -Wl,-O1,--sort-common,--as-needed,-z,relro"
そして makepkg を以下のように実行してください:
$ linux32 makepkg --config ~/.makepkg.i686.conf
トラブルシューティング
Makepkg によるパッケージの署名に失敗する
gnupg 2.1 から gpg-agent は手動で起動する必要がなくなり、gpg を実行したときに自動的に起動します。gpg-agent を手動で起動しなかったとき makepkg によって起動されます。問題は makepkg が fakeroot で gpg を起動するため、gpg-agent も同じ環境で起動されてしまいます。これによって問題が起こります。makepkg を実行する前に手動で gpg-agent を起動することで解決できますが (詳しくは GnuPG#gpg-agent を参照)、信頼性のある方法ではありません: FS#49946。
gpg-agent の設定に頭を使いたくない場合、署名は後回しにして makepkg を実行し、それから gpg --detach-sign name.pkg.tar.xz
でパッケージに署名する方法もあります。
QMAKE を使用するパッケージで makepkg.conf の CFLAGS/CXXFLAGS/CPPFLAGS が適用されない
Qmake は CFLAGS
と CXXFLAGS
変数を自動的に設定します。makepkg の設定ファイルで定義した変数を qmake に使わせるには、PKGBUILD を編集して QMAKE_CFLAGS_RELEASE と QMAKE_CXXFLAGS_RELEASE 変数を qmake に指定する必要があります。例:
PKGBUILD
... build() { cd "$srcdir/$_pkgname-$pkgver-src" qmake-qt4 "$srcdir/$_pkgname-$pkgver-src/$_pkgname.pro" \ PREFIX=/usr \ QMAKE_CFLAGS_RELEASE="${CFLAGS}"\ QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}" make } ...
もしくは、システム全体で設定したい場合、qmake.conf
を作成して QMAKESPEC 環境変数を設定してください。
QMAKE を使用するパッケージのインストールディレクトリを指定する
qmake によって生成される makefile は INSTALL_ROOT
環境変数を使ってプログラムをインストールするディレクトリを指定します。したがって package 関数を以下のようにしてください:
PKGBUILD
... package() { cd "$srcdir/${pkgname%-git}" make INSTALL_ROOT="$pkgdir" install } ...
また、qmake を正しく設定する必要があります。例えば .pro ファイルに以下を記述してください:
YourProject.pro
... target.path = /usr/local/bin INSTALLS += target ...
プロキシの背後にある時、makepkg は依存関係のダウンロードに失敗します
makepkg が依存関係を呼び出すと、 pacman を呼び出してパッケージをインストールします。これには、 sudo を介した管理者権限が必要です。ただし、 sudoは 環境変数を特権環境に渡さず、プロキシ関連の変数 ftp_proxy
、 http_proxy
、 https_proxy
、 および no_proxy
プロキシの背後で makepkg を機能させるには、次のいずれかの方法を実行する必要があります。
XferCommand で URL を設定して、プロキシを有効にする
XferCommandは、 /etc/pacman.conf
で目的のプロキシURLを使用するように設定できます。 pacman.conf
[5] に次の行を追加するか、コメントを解除します。
/etc/pacman.conf
... XferCommand = /usr/bin/curl -x http://username:password@proxy.proxyhost.com:80 -L -C - -f -o %o %u ...
sudoer の env_keep を介してプロキシを有効にする
あるいは、sudoer の env_keep
オプションを使用することもできます。これにより、特定の変数を特権環境に保持できます。詳細については、 sudo#環境変数 を参照してください。
WARNING: Package contains reference to $srcdir
リテラル文字列 $srcdir
か $pkgdir
があなたのパッケージ内のインストールされたファイルのどれかに含まれています。
ファイルを確認するには、makepkg のビルドディレクトリから次のコマンドを実行してください:
$ grep -R "$(pwd)/src" pkg/
詳しくは こちら を参照。
makepkg は失敗するが、make は成功する
make を使用して手動でコンパイル出来ても、makepkg で失敗する場合、それはほぼ確実に /etc/makepkg.conf
がコンパイル変数を通常は機能する合理的なものに設定されていますが、それは コンパイルしているものと互換性がありません。 これらのフラグを PKGBUILD options
配列に追加してみてください。
!buildflags
、 デフォルトの CPPFLAGS
、 CFLAGS
、 CXXFLAGS
、 および LDFLAGS
を防ぐため。
!makeflags
、 並列ビルドを有効にするために /etc/makepkg.conf
を編集した場合に、デフォルトの MAKEFLAGS
を防ぐため。
!debug
、 デフォルトの DEBUG_CFLAGS
を防ぐため、および DEBUG_CXXFLAGS
(パッケージがデバッグビルドの場合)
これらのいずれかで問題が修正された場合、問題の原因となっているフラグを正確に特定すれば、アップストリームでバグを報告できる可能性があります。
参照
- makepkg(8) マニュアルページ
- makepkg.conf(5) マニュアルページ
- gcccpuopt: 現在の CPU にあわせた gcc の cpu オプションを表示するスクリプト
- makepkg のソースコード