「DeveloperWiki:パッケージャになる方法」の版間の差分

2020年5月17日 (日) 09:31時点における版

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

パッケージガイドラインは 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 を実行

ノート: これは 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 ディレクトリ以下のリポジトリ特有の場所にアップロードします。

リポジトリの更新

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.

@@ 130行目: / 130行目: @@
 === devtools を使って署名・アップロード・コミット ===
+パッケージに満足したら、全ての変更がリポジトリに追跡されていることを確認する必要があります。
-Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository.
+以下のコマンドを {{ic|some-package/trunk/}} ディレクトリで実行します。
-Run:
    svn status
+そして、注意深く出力を確認してください。
-in the {{ic|some-package/trunk/}} directory and check the output carefully.
+例えば新しい {{ic|some-package.install}} ファイルを追加したとすると、svn にそのファイルを追跡するように伝える必要があります。例:
-If, for example, you have added a new {{ic|some-package.install}} file, you need to tell svn to track that file, e.g.:
    svn add some-package.install
+バイナリパッケージ・makepkg ログなどは '''絶対に''' リポジトリに追加しないように確認してください。
-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. {{ic|communitypkg}} for [[公式リポジトリ#community|community]], {{ic|community-stagingpkg}} for [[公式リポジトリ#Staging_repositories|community-staging]], {{ic|community-testingpkg}} for [[公式リポジトリ#community-testing|community-testing]], {{ic|extrapkg}} for [[公式リポジトリ#extra|extra]], {{ic|gnome-unstablepkg}} for [[公式リポジトリ#gnome-unstable|gnome-unstable]], {{ic|kde-unstablepkg}} for [[公式リポジトリ#kde-unstable|kde-unstable]], {{ic|multilibpkg}} for [[公式リポジトリ#multilib|multilib]], {{ic|multilib-stagingpkg}} for [[公式リポジトリ#Staging_repositories|multilib-staging]], {{ic|multilib-testingpkg}} for [[公式リポジトリ#multilib-testing|multilib-testing]], {{ic|stagingpkg}} for [[公式リポジトリ#Staging_repositories|staging]], {{ic|testingpkg}} for [[公式リポジトリ#testing|testing]]), e.g.:
+進める準備ができたら、devtools スクリプトを実行して変更を署名・アップロード・コミットすることができます (例えば {{ic|communitypkg}} は [[公式リポジトリ#community|community]] に、{{ic|community-stagingpkg}} は [[公式リポジトリ#Staging_repositories|community-staging]] に、{{ic|community-testingpkg}} は [[公式リポジトリ#community-testing|community-testing]] に、{{ic|extrapkg}} は [[公式リポジトリ#extra|extra]] に、{{ic|gnome-unstablepkg}} は [[公式リポジトリ#gnome-unstable|gnome-unstable]] に、{{ic|kde-unstablepkg}} は [[公式リポジトリ#kde-unstable|kde-unstable]] に、{{ic|multilibpkg}} は [[公式リポジトリ#multilib|multilib]] に、{{ic|multilib-stagingpkg}} は [[公式リポジトリ#Staging_repositories|multilib-staging]] に、{{ic|multilib-testingpkg}} は [[公式リポジトリ#multilib-testing|multilib-testing]] に、{{ic|stagingpkg}} は [[公式リポジトリ#Staging_repositories|staging]] に、{{ic|testingpkg}} は [[公式リポジトリ#testing|testing]] に使います)、例:
    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.
+これはパッケージと署名を、{{ic|repos.archlinux.org}} 上にあるユーザーの {{ic|~/staging}} ディレクトリ以下のリポジトリ特有の場所にアップロードします。
-This will upload the package and its signature to their repository specific location in your user's {{ic|~/staging}} directory on {{ic|repos.archlinux.org}}.
 === リポジトリの更新 ===