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

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

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

準備とセットアップ

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

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
  # update a specific package
  svn update <package_name>
  # update all packages
  svn update

新しいパッケージの追加

This step is only required when adding a new package to the repository for the first time.

  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

変更とビルド

It is mandatory to build your package using a clean chroot. To ensure this, build with the scripts provided by devtools (i.e. extra-x86_64-build for extra and community, multilib-build for multilib, multilib-staging-build for multilib-staging, multilib-testing-build for multilib-testing, staging-x86_64-build for staging and community-staging, testing-x86_64-build for testing and community-testing).

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

Or, if you are using the ch helper, simply do:

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

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

ノート: This is automatically done, when using the devtools build scripts.

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

パッケージの checkpkg を実行

Run in the directory with your freshly built package to get a file list diff compared with the package version currently in the repos.

   checkpkg

ノート: This can be skipped when adding a new package to the repository for the first time (e.g. by importing it from AUR to community).

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

If checkpkg identified a shared object name (aka. soname) change in package's library package.so, it is required to rebuild packages directly depending on it.

To identify which packages rely on a given library in package in a repository (e.g. extra or community), use sogrep (see sogrep(1)).

   sogrep <repository> package.so

Build package for its respective staging environment (by following the remaining steps in The Workflow) and create a TODO with the identified dependants, so their maintainers can rebuild them against the new version of package.

ノート: First sync with trusted users and/ or developers, if any packages currently in the staging environment block the rebuilds against package.

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

Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository. Run:

  svn status

in the some-package/trunk/ directory and check the output carefully. If, for example, you have added a new some-package.install file, you need to tell svn to track that file, e.g.:

  svn add some-package.install

Make sure to never add the binary packages, makepkg logs, etc. to the repository!

When you're ready to proceed, you can run the devtools scripts to sign, upload and commit your work (i.e. communitypkg for community, community-stagingpkg for community-staging, community-testingpkg for community-testing, extrapkg for extra, gnome-unstablepkg for gnome-unstable, kde-unstablepkg for kde-unstable, multilibpkg for multilib, multilib-stagingpkg for multilib-staging, multilib-testingpkg for multilib-testing, stagingpkg for staging, testingpkg for testing), e.g.:

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

Please try to write concise commit messages. If the package is simply an upstream change, that is fine, but if anything more complex changes, please inform us by writing an appropriate commit message.

This will upload the package and its signature to their repository specific location in your user's ~/staging directory on repos.archlinux.org.

リポジトリの更新

Using db-update will find new packages for a set of repositories, depending on which is being called.

To release uploaded packages to core, extra, gnome-unstable, kde-unstable, staging, or testing use:

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

To release uploaded packages to community, community-staging, community-testing, multilib, multilib-staging, or multilib-testing use:

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

他の操作

パッケージの削除

Using db-remove will remove a package from a specific binary repository.

To remove a package from core, extra, gnome-unstable, kde-unstable, staging, or testing use:

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

e.g.

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

To remove a package from community, community-staging, community-testing, multilib, multilib-staging, or multilib-testing use:

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

e.g.

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

If removing the package from the repositories altogether, it is encouraged to remove the entire package directory from version control as well.

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

Sometime the previous command yields:

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

You can remotely remove it with:

   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.