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 # 特定のパッケージをアップデート 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 を実行
namcap PKGBUILD namcap some-package-1.0-1-x86_64.pkg.tar.xz
パッケージの checkpkg を実行
パッケージをビルドしたディレクトリで実行して、現在リポジトリにあるパッケージのバージョンと比較したファイルリストの差分を得ることができます。
checkpkg
識別された soname の変更に sogrep を実行
checkpkg が共有オブジェクト名 (別名 soname) の変更を package
のライブラリ package.so
で見つけた場合、直接それに依存するパッケージをリビルドすることが 必要 です。
リポジトリ (例えば extra
や community
) 内のどのパッケージが package
内のライブラリに依存しているかを特定するには、sogrep を使ってください (sogrep(1) も参照)。
sogrep <repository> package.so
(ワークフロー の残りのステップを実行することで) 対応する staging 環境で package
をビルドしたら、特定された依存パッケージの TODO を作成して、依存パッケージのメンテナが新しいバージョンの 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"
他の操作
パッケージの削除
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.