DeveloperWiki:パッケージャになる方法

パッケージガイドラインに従う

パッケージガイドラインは Arch Linux ドキュメントにあります。しっかりと従ってください。

Arch パッケージガイドライン

準備とセットアップ

パッケージのインストール

devtools と namcap パッケージがインストールされていることを確認してください。

SSH 設定

SSH エージェントに複数の SSH キーを登録している場合、Arch のサーバーと接続する際に正しいキーが使われるようにする必要があります。 さらに、ローカルのユーザー名が Arch のサーバーに接続する際に使うユーザー名と異なる場合も同じように設定する必要があります。

例の ~/.ssh/config の抜粋:

host repos.archlinux.org
	hostname repos.archlinux.org
	port 22
	user foobar
	IdentityFile ~/.ssh/id_arch
	IdentitiesOnly yes

makepkg 設定

~/.makepkg.conf で正しい PACKAGER と GPGKEY 変数を設定していることを確認してください。 間違った署名が付けられていたり PACKAGER がなかったりすると、パッケージをリポジトリに入れることができません。

PACKAGER="Foo Bar <foo.bar@archlinux.org>"
GPGKEY="0x0123456789abcdef"

非再帰的チェックアウトを使ったローカルの SVN セットアップ

SVN は範囲を絞ったチェックアウトが可能なため、空のローカルチェックアウトを初期化して、必要なパッケージだけを後で取得することができます。 ローカルチェックアウトをセットアップするには以下のコマンドを実行します。

core・extra・testing・staging リポジトリには以下のコマンドを使用します。

  svn checkout -N svn+ssh://svn-packages@repos.archlinux.org/srv/repos/svn-packages/svn svn-packages

community・community-testing・community-staging・multilib・multilib-testing・multilib-staging リポジトリには以下のコマンドを使用します。

  svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community

これは svn-packages と svn-community という名前の2つのディレクトリを作成します。中身は空ですが、svn リポジトリとして正しくセットアップされています。

ヘルパースクリプト (任意)

ch

このシェルスクリプトはパッケージをビルドするために chroot をセットアップして維持することを素晴しく簡単にします。 スクリプトは Bluewind により開発され、ch から入手できます。

スクリプトは Btrfs に依存しているため、Btrfs ボリュームを作る必要があります (20GiB あればほとんどの場合十分です)。ファイル・論理ボリューム・専用のパーティションのどれでも構いません。 さらにデフォルトでこのスクリプトは chroot のための Btrfs ボリュームが /mnt/chroots/arch にマウントされていることを想定しています。

その後、以下のコマンドで 64bit パッケージを作ることができます。

  ch build 64

(自動的かつ便利に、全ての必要な引数と共に makechrootpkg コマンドが呼び出されます。)

詳しい情報については、スクリプトの先頭を参照してください。説明と使用例があります。

ワークフロー

ローカルリポジトリのチェックアウト・更新

  cd svn-community
  # 特定のパッケージをアップデート
  svn update <package_name>
  # 全てのパッケージをアップデート
  svn update

新しいパッケージの追加

このステップは新しいパッケージを初めてリポジトリに追加するときだけ必要です。

  cd svn-community
  mkdir -p new-package/{repos,trunk}
  cd new-package
  cp /usr/share/pacman/PKGBUILD.proto trunk/PKGBUILD
  $EDITOR trunk/PKGBUILD
  svn add .
  svn commit

必要なパッケージの更新

  svn update some-package

変更とビルド

パッケージをクリーンな chroot を使ってビルドすることが 必須 です。 これを確実にするために、devtools により提供されるスクリプトを使ってビルドしてください (例えば extra-x86_64-build は extra と community に、multilib-build は multilib に、multilib-staging-build は multilib-staging に、multilib-testing-build は multilib-testing に、staging-x86_64-build は staging と community-staging に、testing-x86_64-build は testing と community-testing に使います)。

  cd some-package/trunk/
  $EDITOR PKGBUILD
  extra-x86_64-build

あるいは、ch ヘルパーを使っている場合は単純に以下を実行してください。

  cd some-package/trunk/
  $EDITOR PKGBUILD
  ch clean 64
  ch update 64
  ch build 64

PKGBUILD とパッケージに namcap を実行

ノート: これは devtools のビルドスクリプトを使うと自動的に実行されます。

  namcap PKGBUILD
  namcap some-package-1.0-1-x86_64.pkg.tar.xz

パッケージの checkpkg を実行

パッケージをビルドしたディレクトリで実行して、現在リポジトリにあるパッケージのバージョンと比較したファイルリストの差分を得ることができます。

   checkpkg

ノート: これは新しいパッケージを初めてリポジトリに追加するときには省略できます (例えば AUR から community にパッケージをインポートしたとき)。

識別された soname の変更に sogrep を実行

checkpkg が共有オブジェクト名 (別名 soname) の変更を package のライブラリ package.so で見つけた場合、直接それに依存するパッケージをリビルドすることが 必要 です。

リポジトリ (例えば extra や community) 内のどのパッケージが package 内のライブラリに依存しているかを特定するには、sogrep を使ってください (sogrep(1) も参照)。

   sogrep <repository> package.so

(ワークフロー の残りのステップを実行することで) 対応する staging 環境で package をビルドしたら、特定された依存パッケージの TODO を作成して、依存パッケージのメンテナが新しいバージョンの package に対してリビルドできるようにします。

ノート: はじめに trusted users や developers と同期してください。staging 環境に現在パッケージがあれば、package に対するリビルドをブロックします。

devtools を使って署名・アップロード・コミット

パッケージに満足したら、全ての変更がリポジトリに追跡されていることを確認する必要があります。 以下のコマンドを some-package/trunk/ ディレクトリで実行します。

  svn status

そして、注意深く出力を確認してください。 例えば新しい some-package.install ファイルを追加したとすると、svn にそのファイルを追跡するように伝える必要があります。例:

  svn add some-package.install

バイナリパッケージ・makepkg ログなどは 絶対に リポジトリに追加しないように確認してください。

進める準備ができたら、devtools スクリプトを実行して変更を署名・アップロード・コミットすることができます (例えば communitypkg は community に、community-stagingpkg は community-staging に、community-testingpkg は community-testing に、extrapkg は extra に、gnome-unstablepkg は gnome-unstable に、kde-unstablepkg は kde-unstable に、multilibpkg は multilib に、multilib-stagingpkg は multilib-staging に、multilib-testingpkg は multilib-testing に、stagingpkg は staging に、testingpkg は testing に使います)、例:

  extrapkg "update to 1.2.3, add post_upgrade hook to fix permissions"

簡潔なコミットメッセージを書くようにしてください。 パッケージが単純なアップストリームの変更であればそれで構いませんが、何かより複雑な変更があれば、適切なコミットメッセージを書いて知らせてください。

これはパッケージと署名を、repos.archlinux.org 上にあるユーザーの ~/staging ディレクトリ以下のリポジトリ特有の場所にアップロードします。

リポジトリの更新

db-update を使って一連のリポジトリから、呼び出されたパッケージに従って新しいパッケージを探すことができます。

アップロードされたパッケージを core・extra・gnome-unstable・kde-unstable・staging・testing にリリースする場合は次のコマンドを使用します。

  ssh repos.archlinux.org "/packages/db-update"

アップロードされたパッケージを community・community-staging・community-testing・multilib・multilib-staging・multilib-testing にリリースするには次のコマンドを使用します。

  ssh repos.archlinux.org "/community/db-update"

他の操作

パッケージの削除

db-remove を使用して、指定したバイナリリポジトリからパッケージを削除することができます。

core・extra・gnome-unstable・kde-unstable・staging・testing からパッケージを削除するには以下のコマンドを使用します。

  ssh repos.archlinux.org "/packages/db-remove <repo> <arch> <package_name>"

例

  ssh repos.archlinux.org "/packages/db-remove core x86_64 openssh"

community・community-staging・community-testing・multilib・multilib-staging・multilib-testing からパッケージを削除するには以下のコマンドを使用します。

  ssh repos.archlinux.org "/community/db-remove <repo> <arch> <package_name>"

例

  ssh repos.archlinux.org "/community/db-remove community x86_64 jack2"

リポジトリからパッケージを完全に削除した場合、パッケージディレクトリ全体をバージョンコントロールからも削除することが推奨されます。

   svn update <package_name>
   svn rm --force <package_name>
   svn commit <package_name> -m "Deleting <package_name> because of reason."

上記のコマンドは時々以下のようなメッセージを出力します。

   svn: E155035: "'/path/to/pkg/<PKG>' is the root of a working copy and cannot be deleted"

リモートから削除するには以下のコマンドを使用できます。

   svn rm svn+ssh://svn-packages@repos.archlinux.org/srv/repos/svn-packages/svn/<PKG>

リポジトリ間でのパッケージの移動

Using db-move will move a package between two binary repositories.

To move a package somewhere between core, extra, gnome-unstable, kde-unstable, staging, or testing use:

  ssh repos.archlinux.org "/packages/db-move <from_repo> <to_repo> <package_name>"

e.g.:

  ssh repos.archlinux.org "/packages/db-move testing core openssh"

To move a package somewhere between community, community-staging, community-testing, multilib, multilib-staging, or multilib-testing use:

  ssh repos.archlinux.org "/community/db-move <from_repo> <to_repo> <package_name>"

e.g.:

  ssh repos.archlinux.org "/community/db-move community-testing community jack2"

Alternatively, the move from testing is so common, that there are helper scripts:

  /packages/testing2x openssh bzip2 coreutils
  /packages/testing2x64 openssh bzip2 coreutils

These scripts only work if the packages on the commandline are either in core or extra. If a package is only in testing, you have to use testing2core, testing2core64, testing2extra or testing2extra64.

For the special case of moving a binary package and its version controlled PKGBUILD (and potentially additional files) between community and extra (either direction), there are the two devtools helper scripts community2extra and extra2community.

E.g. to move a a package from community to extra, use:

   community2extra <package_name>

リリースの "タグ付け"

Fetch the package dir using archco or communityco or from an svn checkout. Then:

  cd package-name/trunk
  archrelease extra-x86_64

This makes an svn copy of the trunk entries in a directory named extra-x86_64 indicating that this package is in the extra repository for the x86_64 architecture. This will be done automatically when using tools such as extrapkg (see Use devtools to sign, upload and commit).

その他

チェックアウトのクリーンアップ

Since you are now maintaining a non-recursive checkout, you may want to get rid of packages that you are no longer tracking:

  svn update package1 package2 --set-depth exclude

Or if you want an empty toplevel again:

  svn update --set-depth empty

毎回のパスワード入力を省略する

When working with extrapkg and the other devtools, quite a few ssh connections are established, even when using ssh keys and the ssh agent. You can work around that.

Add this to your ~/.ssh/config:

  ControlPath ~/.ssh/master-%h-%p-%r
  
  Host repos.archlinux.org

Now, before you start working, open a ssh session with

  ssh -M repos.archlinux.org

Enter your password and leave that session open until you are finished. All ssh sessions (including scp and svn+ssh) will now be tunneled through this connection.