Arch Linuxでのパッケージのビルド（AURを含む）

• PKGBUILD
• PKGBUILD / ETCの入手
• PKGBUILD / ETCのアップグレード
• コンパイル
• ローカルリポジトリ
• より速くコンパイル
• PGP署名エラー
• AUR開発パッケージ
• 古いパッケージ

Arch Linuxでは、公式リポジトリはコア、エクストラ、コミュニティです。これらのパッケージは既にコンパイルされており、を通じてインストールされますpacman。ほとんどの場合、一般ユーザーはこれらの3つの公式リポジトリが別個であることを無視できます。コアには、カーネル、ブートプロセス、ネットワーク、パッケージ管理、opensshなどの最も重要なパッケージが含まれています。また、新しいバージョンがリリースされる前に、より徹底的なテストを行うという厳しい要件もあります。Extraには、Xサーバー、ウィンドウマネージャー、Webブラウザーなど、それほど重要ではない他の一般的なパッケージが含まれています。コミュニティにはあまり人気のないパッケージが含まれています。信頼できるユーザー（他の信頼できるユーザーによって投票された約60人のアクティブユーザー）のみが、公式リポジトリを変更するためのアクセス権を持っています。

2019年には、公式リポジトリのhttps://www.archlinux.org/packagesに約11,000個のパッケージがあります。しかし、Linuxで利用できる他の多くのプログラムがあります。そのため、AUR（Arch Linux User Repository）が存在するため、Archユーザーは新しいプログラムを追加してそのメンテナーになるか、現在のメンテナーがいない「孤立した」パッケージを採用できます。AURのhttps://aur.archlinux.org/に約55,000個のパッケージがあります。

AURには3つの重要な違いがあります：

1. 繰り返しになりますが、これらのパッケージは、まったく新しいユーザーでも作成できます。
2. AURはPKGBUILD、コンパイルされたバイナリではなく、パッケージを自動的に作成するためのシェルスクリプトであるのみを格納します。（時には、小さなテキストパッチ、またはシェルスクリプトのインストール/アップグレード/アンインストールも含まれます）。これは、誰かが悪意のあるコードを配布できる可能性を軽減しながら、すべてのユーザーが貢献できるようにするという途方もない仕事をしました。ArchコミュニティはAURパッケージの問題に関してはまだかなり役に立ちますが、それらの使用はあなた自身のリスクであることが指摘されています。提供するのはだけPKGBUILDなので、使用するを確認するのは最終的にはあなたの責任PKGBUILDです。（当然のことながら、多くのユーザーはこれを行わず、他のユーザーに頼って監視を続けています。）
3. pacmanはAURと直接対話しないため、AURパッケージを更新するのはユーザーの責任です。を介してシステム全体を定期的にアップグレードする場合、pacmanAUR PKGBUILDファイルへのアップデートを自動的にダウンロードしてコンパイルし、インストールすることはありません。

この記事ではAURからのパッケージの構築に焦点を当てていますが、同じ手法を使用して、公式リポジトリから自分でパッケージを構築することもできます。

PKGBUILD

.spec他の多くのディストリビューションが使用するファイルと比較すると、a PKGBUILDは短くて単純なシェルスクリプトです。一部のパッケージはより複雑ですが、単純に次のようになります。

pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc='DESCRIPTION'
url=http://example.com/
arch=('x86_64')
license=('GPL2')
source=(http://example.com/downloads/${pkgname}-${pkgver}.tar.gz)
sha256sums=('f0a90db8694fb34685ecd645d97d728b880a6c15c95e7d0700596028bd8bc0f9')

build() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   ./configure
   make
}

package() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   make install
}

このドキュメントは次を参照しています：

• PKGNAME：パッケージの名前
• PKGVER：パッケージのバージョン（ほとんどの場合、アップストリームのバージョン番号と一致します）
• PKGREL：PKGBUILD特定ののArchの「バージョン」PKGVER（通常は1ですがPKGBUILD、上流のリリース間で変更を加える必要がある場合は増分されます）
• ARCH：パッケージを構築できるアーキテクチャ（Arch Linux公式リポジトリは "x86_64"（64ビットCPU）のみをサポートするため、レガシーですが、AURパッケージは "i686"（32ビットCPU）または "any"をサポートできますアーキテクチャを指定することは無関係です）
• PKGBUILD/ETC：実際にAURリポジトリにあるファイル。PKGBUILD、およびその他の小さなテキストパッチ、またはアップグレード/アンインストールシェルスクリプトを/インストールしてください。上流ファイルをsource配列に含めません。

AURは非常に信頼できることが証明されていますが、信頼できるPKGBUILD/ETC場所からソースを取得していることを確認するためにを確認することをお勧めします。（たとえば、githubからのものである可能性のある公式の上流の場所-しかし、上流のパッケージに関係のないランダムな人のgithubリポジトリだけではありません）; PKGBUILD/ETC疑わしいコードは含まれていません。

入手 PKGBUILD/ETC

AURから

インストールするパッケージが公式リポジトリに含まれていない場合は、https：//aur.archlinux.org/で検索してください。うまくいけば、あなたが探しているものが存在し、最新で維持されていることがわかるでしょう。

PKGBUILD/ETCAURからを取得する最良の方法は、を介してクローンを作成することgitです。

インストールしgitていない場合は、インストールします。

# pacman -S git

AUR Webサイトに表示されている「Git Clone URL」を使用して、そのパッケージを取得します。

$ git clone https://aur.archlinux.org/fslint.git

ディレクトリに入り、その内容を確認します。（を除いてすべては、ここに記載され. .. .gitていますPKGBUILD/ETC）：

$ cd <PKGNAME>
$ ls -a
.  ..  .git  PKGBUILD  .SRCINFO

を調べるPKGBUILDと、公式のアップストリームソースコードを使用しており、パッケージを構築するための一般的な手順を実行していることがわかります。そのため、信頼できるようです。に.SRCINFOはパッケージに関するWebサイトに表示される情報が含まれているだけなので、心配する必要はありません。ここに他のファイルがある場合、それらは上流から（直接）提供されPKGBUILDていないため、疑わしい内容が含まれていないことを確認するために、ファイルとでの使用方法を調べる必要があります。

公式リポジトリから

それほど頻繁に必要になることはありませんが、公式リポジトリにすでにあるパッケージをビルドして、新しいパッチを含めたり、新しいバージョンをビルドしたりできます。

PKGBUILD/ETCコアおよび追加のリポジトリから取得します。

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/packages.git "<PKGNAME>"

コミュニティリポジトリから：

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/community.git "<PKGNAME>"

アップグレード PKGBUILD/ETC

アップグレードPKGBUILD/ETCがリリースされた場合は、を使用して作成したこのディレクトリに戻ってgit clone、それらを更新できます。

$ git pull

次に、以下の選択した方法を使用して、パッケージを再コンパイルおよびアップグレードします。

コンパイル

パッケージをコンパイルするには多くの方法があります。最終的に、すべてがを使用しmakepkgます。正式にサポートされている方法は2つあります。

• を直接使用するmakepkgには、https：//www.vultr.com/docs/using-makepkg-on-arch-linuxを参照してください。
• makepkgクリーンchrootで間接的に使用するには、https：//www.vultr.com/docs/using-devtools-on-arch-linuxを参照してください。

そこ（のような多くのAURヘルパープログラムされているmakepkgような正式アーチでサポートされていないラッパーは）、、 、aurutils、yay最近で中止aurmanとyaourt。これらの他のヘルパープログラムのいずれかを使用している場合でも、何かがうまくいかない場合により効果的になるために公式にサポートされている方法をよく理解することを強くお勧めします。

このドキュメントの残りの部分では、YOUR BUILDER選択した方法を意味します。

ローカルリポジトリ

ビルドするすべてのパッケージの中心的な場所になるようにローカルリポジトリを設定できます。

ローカルリポジトリを好きな場所に配置します。

# mkdir /archLocalRepo

YOUR BUILDER自動インストールオプションなしで実行し、パッケージをローカルリポジトリにコピーします。

# cp <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz /archLocalRepo

新しいパッケージをリポジトリインデックスに追加します。

# repo-add /archLocalRepo/archLocalRepo.db.tar.gz /archLocalRepo/<PACKAGE-FILE-NAME>

リポジトリのインデックスとパッケージファイル自体からパッケージを削除するには：

# repo-remove /archLocalRepo/archLocalRepo.db.tar.gz <PKGNAME>
# rm /archLocalRepo/<PACKAGE-FILE-NAME>

既存のパッケージファイルを置き換える必要がある場合は、置き換えられるファイルを個別に削除してから、新しいファイルを追加する必要があります。新しいファイルを古いファイルに単純にコピーすることはできません。

をpacman編集してローカルリポジトリを使用するように設定/etc/pacman.confし、最後に以下を追加します。

[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo

pacmanリポジトリ（ローカルのものを含む）データベースの知識を更新する必要があります。追加したパッケージを確認するには：

# pacman -Sy

その後、公式リポジトリにある場合と同じように、パッケージをインストールできます。

# pacman -S <PKGNAME>

パッケージが、インストールする別のパッケージの依存関係にすぎない場合は、直接インストールする必要はありません。この他のパッケージpacmanをインストールすると、ローカルのリポジトリで依存パッケージが自動的に検出されてインストールされます。

より速くコンパイル

デフォルトではYOUR BUILDER、シングルスレッドを使用してコンパイルします。マルチCPUシステムでは、可能な場合は複数のスレッドの使用を許可できます。ビルドシステムは、可能な場合、ソースコードの一部を並行してコンパイルします。コードの一部が、すでにコンパイルされているために相互作用する他の部分を必要とする場合があるため、常に使用されているスレッドの数が許可されているとは限りません。編集/etc/makepkg.conf。

仮想コアと同じ数のスレッドを使用できるようにするには、以下を追加します。

MAKEFLAGS="-j$(nproc)"

注： これによりコマンドがnproc毎回実行されるため、Vultrサーバーをアップグレードする場合に備えて、常に現在のコア数が使用されます

システム全体のパフォーマンスへの影響を減らすなど、複数の仮想コアを使用できるようにするには、特定の数を追加します。たとえば、24コアの場合、21を使用することができます。

MAKEFLAGS="-j21"

使用している仮想コアの数より多くのスレッドを指定すると、パフォーマンスが低下します。

これはかなりまれですが、一部のパッケージのビルドシステムでは、コードの部分間の依存関係を適切に定義していないため、並列コンパイルに問題があります。通常、これらのパッケージのPKGBUILDファイルはmake -j1、を呼び出してこれを処理します。これにより、設定したデフォルトが上書きされます。これが必要で欠けている場合は、Archパッケージのメンテナに報告してください。

PGP署名エラー

PKGBUILDソース配列を含むことができます.ascまたは.sigファイル。それらはbash brace展開を使用して含まれることが多いため、見落としがちです。

source=("http://example.com/downloads/${pkgname}-${pkgver}.tar.gz{,.sig}")

これらの形式の署名ファイルのいずれかがソース配列に含まれている場合、はYOUR BUILDER自動的に上流のソースアーカイブの署名の検証を試みます。署名のPGP鍵はユーザーの鍵リングに含まれている必要があります。それ以外の場合は、次のエラーで中止されます。

==> Verifying source file signatures with gpg...
    <SOURCE-FILE> ... FAILED (unknown public key 1234567890ABCDEF)
==> ERROR: One or more PGP signatures could not be verified!

GPGキーはいくつかの方法で表示できることを理解することが重要です。その指紋は40桁の16進文字であり、常に使用する必要があります。長いキーIDは最後の16桁で、短いキーIDは最後の8桁です。短くすると便利ですが、重複を許可して、署名の検証の背後にあるすべての理由を無効にします。さらに悪いことに、攻撃者は知名度の高い開発者のために、短い長さのキーと一致する偽のキーを生成することが知られています。

PGPキーフィンガープリントの取得と確認

パッケージのビルドをまだ行っていない場合は、署名ファイルを含むソースをダウンロードします（ビルドを試みた場合は、すでにそこにあります）。

$ makepkg --nobuild --noextract

完全な指紋を取得するには：

$ gpg <ASC-OR-SIG-FILENAME>
...
gpg:                using RSA key 155D3FC500C834486D1EEA677FD9FCCB000BEEEE
...

理想的には、上流からこのフィンガープリントを確認する必要があります。安全を確保するために、アップストリームはWebサイトまたはソースのどこかにメンテナのキーを提供する必要があります。キーサーバーでキーを検索するだけでは、実際には何も実行されません。キーサーバーは信頼性を検証しないため、攻撃者は偽のキーを簡単に送信できます。鍵は他の鍵で署名できるため、信頼できる鍵がすでにある場合は、それらが署名したすべての鍵をかなり安全に信頼する必要があります。

これはかなりの作業になる可能性があります。特に、アップストリームが指紋を公開したり、見つけやすい場所に置いたりしない場合は特にそうです。にはArchのメンテナによって追加さPKGBUILDれたvalidpgpkeys配列が含まれます。パッケージが公式リポジトリである場合、それは信頼されたユーザーがパッケージを配置したことを意味し、配列にリストされているものを信頼するだけでかなり安全です。パッケージがAURにある場合は、別のArchユーザーがパッケージをそこに置いたことを意味することに注意してください。それを信頼することに不安がある場合は、いつでもユーザーを調べて、Archを使用して過去に行ったことを確認できます。

鍵リングにPGP鍵を追加する

キーリングに指紋を追加するには：

$ gpg --recv-keys <FINGERPRINT>

YOUR BUILDERこれでを実行でき、指紋を信頼します。

AUR開発パッケージ

終わる名前を持つAURパッケージ-git、-svn、-bzrまたは-hg上流の最新のリリースだの上流の最新バージョン管理システムを使用している発達のバージョンでは、代わりにコミット。たとえば、-gitパッケージは、マスターブランチ（または同等のブランチ）でアップストリームの最新のコミットを使用します。これは、まだリリースされていないアップストリームのバグ修正と新機能を実行するのに最適です。それらについては、リリースに含まれていないコミットによって修正されたバグではないことを確認する必要があります。これらのパッケージは潜在的に不安定であると考えられるべきです。とはいえ、残念ながら、一部の上流のメンテナはリリースにタグ付けしないか、タグ付けリリース間で過度に長くなり、誰もが最新のコミットを使用することを期待しているため、代替手段がない場合があります。パッケージによっては、あなたがそのコミットを実行しようとする最初の人かもしれません。上流の開発者によっては、最新のコミットがコンパイルされないことさえあり、

よくある間違いを理解することが重要です。古いバージョン番号が表示されているからといって、AUR開発パッケージに古いフラグを付けないでください！開発パッケージPKGBUILDファイルには、アップストリームのソースコードからpkgver()更新されたものを自動的に解析するために使用される追加の関数が含まれていPKGVERます。-gitパッケージの一般的な形式は<TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>です。AURにはパッケージが含まれ5.0.0.r102.8d7b42ac21-1ているため、パッケージはとしてリストされる場合がありPKGBUILDます。ただし、パッケージを作成すると、YOUR BUILDERは自動的に更新PKGVERされ、新しくダウンロードされたソースコードを反映します。実際、多くの新しいバージョンがリリースされたが、ビルドプロセスで何も変更されていない場合、このようなPKGBUILD古いバージョンのリストは、次のようなより新しい何かをビルドすることになります。9.1.2.r53.2c9a41b723-1。これらのパッケージの場合、ウェブサイトにリストされているバージョンは、AURメンテナーが最後にを更新しなければならなかったときの最新バージョンPKGBUILDです。

AURのメンテナは、PKGVER新しいバージョンを反映するために単にを更新することは想定されていません。新しいアップストリームのコミットが実際PKGBUILDに変更するために何か他のものを必要とするときだけそれらはそうすることになっています。

何かが実際に間違っていることがわかっている場合にのみ、開発中のAURパッケージに古いフラグを付けます。つまり、実際に使用してみましたが、適切にフォーマットされたnewのコンパイルまたは解析に失敗しましたPKGVER。時々PKGBUILD、上流の依存関係の変更、configureオプションの変更、新しいGCCバージョンが以前のものではなかったソースコードのエラーをピックアップする、上流のリポジトリの場所が変更される、上流の開発者が典型的なバージョンを変更するなど、AURメンテナにを強制的に更新することが起こりますソースコード内にあり、PKGVER解析機能。コンパイルまたは機能しない場合でも、AURメンテナーがビルドプロセスに変更を加える必要があるか、AURメンテナーが責任を負わないソースコードの上流の問題である可能性があることを理解してください。

古いパッケージ

パッケージが古くなっていると報告する前に、上記の「AUR開発パッケージ」セクションを必ずお読みください。

アップストリームが非開発用パッケージの新しいバージョンをでリリースした場合はPKGBUILD、[パッケージのフラグを古くする]をクリックして、メンテナへのメッセージを入力できます。公式リポジトリパッケージにはhttps://packages.archlinux.orgを、AURパッケージにはhttps://aur.archlinux.orgを使用してください。役立つメッセージは、新しいバージョン番号と、おそらくリリースのお知らせまたはソースコードへのリンクです。フラグ機能はあなたのメッセージをメンテナに自動的にメールします。

AURパッケージでは、2週間経過しても応答がない場合、信頼されたユーザーに現在のメンテナーを削除するよう依頼し、パッケージを孤立させるには、「Orphan」タイプの[Submit Request]をクリックします。メンテナは孤立したリクエストに応答しません。一般的に、孤立したリクエストを提出できるのは、パッケージを引き継ぐことができ、その意思がある場合のみです。できれば、currentがすでに機能している場合に限りPKGBUILDます。

それまでの間、古いパッケージを自分で更新できることがよくあります。多くの場合、を変更するだけで新しいバージョン番号にPKGBUILD更新する必要がありPKGVER、整合性の合計が更新されます。プログラムupdpkgsumsはパッケージpacman-contribに存在します。これは自動的に合計を計算し、で更新しPKGBUILDます。アップストリームのリリースノートをチェックして、新しいバージョンのインストールプロセス中に何か変更する必要があると述べているかどうかを確認することは価値があります。アップストリームの変更により、への変更またはオーバーホールが必要になる場合がありますPKGBUILD/ETC。多くの場合、source配列はその中に埋め込まPKGVERれているため、更新する必要さえありません。