Fedoraプロジェクトでパッケージを更新するには

はじめに

以前、Fedoraプロジェクトで新規パッケージをリリースする方法という記事を書きました。パッケージを初めてFedoraプロジェクトでリリースしようとしているときに、どんなことをするのかというのを実際の例にもとづいて紹介する内容でした。

今回はパッケージをリリースした後の話として、既存パッケージを更新するときにどうすればいいのか、というのをカラムストア機能付き全文検索エンジンであるgroongaを例に紹介します。

既存パッケージの更新作業の流れ

Fedoraプロジェクトで既存のパッケージを更新するケースは二つあります。一つは、自分で新規にパッケージを追加したものを引き続き更新する場合です。もう一つは、他の人がメンテナンスしているパッケージを更新する場合です。前者と後者では、パッケージの所有者に共同メンテナとして認めてもらう必要があるという違いがあります。ただし、その違いさえ除けばあとの作業は同じです。

以下に既存パッケージの更新作業の流れを簡単に紹介します。

共同メンテナになる（他の人がメンテナンスしているパッケージに参加する場合）
新規リリースを取り込む
SRPMを作成する
ビルドチェックする
パッケージをコミットする
パッケージをビルドする
パッケージをアップデートする
パッケージをリリースする

既存パッケージの更新についてはPackage update HOWTOという文書があるので、一読をおすすめします。

groongaの場合は、すでにFedoraプロジェクトにパッケージが登録されていました。ただし、groongaが毎月29日に肉の日リリースを定期的に行っていることもあり、最新バージョンが利用できる状態にはありませんでした¹。

そこで、共同メンテナになることにしました。

共同メンテナになる

共同メンテナになるには、Fedora Pacakge Databaseにアクセスし、FASアカウント²によるログインが必要です。

パッケージ名で検索し、詳細ページで自身をメンテナとして登録します。登録するとパッケージの所有者に通知が送られます。

あとは共同メンテナになりたい旨をメール等で交渉します。groongaの場合は、こちらからお願いする前にパッケージの所有者である上野さんから共同メンテナになる意思確認のメールをもらいました。そのためその後のやりとりで、共同メンテナとしてすぐに承認してもらえました。

新規リリースを取り込む

共同メンテナとして承認してもらったら、実際に更新作業に入ります。groongaの場合、リポジトリの以下の三つのブランチで更新する必要があります。

master³
f19
f18

masterブランチを更新し、その変更を別のブランチにマージしなければなりません。注意すべきは、masterブランチとそれ以外では若干手順に違いがあることです。これについては「ブランチごとの作業まとめ」で後述します。

以下のコマンドでgroongaのリポジトリをcloneしてからソースアーカイブを更新します。

$ fedpkg clone groonga
$ cd groonga
$ wget http://packages.groonga.org/source/groonga/groonga-3.0.4.tar.gz
$ fedpkg new-sources groonga-3.0.4.tar.gz

実行すると、以下のようにソースアーカイブがアップロードされます。

Uploading: d37e6391f9a7346166e0d1301e88dea5  groonga-3.0.4.tar.gz
######################################################################## 100.0%
Uploaded and added to .gitignore: groonga-3.0.4.tar.gz
Source upload succeeded. Don't forget to commit the sources file

fedpkg new-sourcesは.gitignoreやsourcesファイルを更新します。しかしspecファイルはそのままなので、エディタでgroonga.specを適宜修正します。groongaの場合は特にパッケージ構成やスクリプトの変更等はなかったので、修正したのはchangelogやRelease、Versionくらいでした。

specファイルの修正が終わったら、次のステップ「SRPMを作成する」へ進みます。

SRPMを作成する

ビルド確認に使うSRPMを作成します。

SRPMを作成するには以下のコマンドを実行します。

$ fedpkg srpm

SRPMがカレントディレクトリに作成されたら、次のステップ「ビルドチェックする」へ進みます。

ビルドチェックする

作成したSRPMをもとにビルドに支障がないか確認します。

そのままrpmbuildでビルドを確認するという方法もあります。ただし通常利用している環境でのビルド確認ではパッケージの依存関係の漏れを見過す可能性があるので、以前紹介したKojiを使って確認します。例えば、Fedora 19向けのビルド確認をするには以下のコマンドを実行します。

$ koji build --scratch --arch-override x86_64 f19 groonga-3.0.4-1.fc20.src.rpm

すると以下のようにFedoraのビルドサーバーにSRPMがアップロードされ、パッケージのビルドが始まります。

Uploading srpm: groonga-3.0.4-1.fc20.src.rpm
[====================================] 100% 00:00:34   9.87 MiB 289.95 KiB/sec
Created task: 5436609
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5436609
Watching tasks (this may be safely interrupted)...
5436609 build (f19, groonga-3.0.4-1.fc20.src.rpm): free
5436609 build (f19, groonga-3.0.4-1.fc20.src.rpm): free -> open (buildvm-07.phx2.fedoraproject.org)
  5436610 buildArch (groonga-3.0.4-1.fc20.src.rpm, x86_64): open (buildvm-23.phx2.fedoraproject.org)
  5436610 buildArch (groonga-3.0.4-1.fc20.src.rpm, x86_64): open (buildvm-23.phx2.fedoraproject.org) -> closed
  0 free  1 open  1 done  0 failed
5436609 build (f19, groonga-3.0.4-1.fc20.src.rpm): open (buildvm-07.phx2.fedoraproject.org) -> closed
  0 free  0 open  2 done  0 failed

5436609 build (f19, groonga-3.0.4-1.fc20.src.rpm) completed successfully

他の環境でもビルドを試すにはkojiのオプションを変更します。例えば、Fedora 18向けにビルドするには以下のようにします。

$ koji build --scratch --arch-override x86_64 f18 groonga-3.0.4-1.fc20.src.rpm

パッケージに問題がないか確認する方法はほかにもいくつかあります。

rpmlintによるチェック
mockによるビルドチェック
fedora-reviewによるチェック

詳細は、「Fedoraプロジェクトで新規パッケージをリリースする方法」の「レビューリクエストの準備」を参照してください。

masterのパッケージをコミットする

ローカルでの動作確認やkojiでのビルド結果に問題がなければ、コミットした後にリポジトリへとpushします。リポジトリへの反映は以下のコマンドを実行します。

$ fedpkg commit
[master 8e64aaf] Update to 3.0.4-1
 3 files changed, 6 insertions(+), 2 deletions(-)

$ git push
Counting objects: 9, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 503 bytes, done.
Total 5 (delta 2), reused 0 (delta 0)
remote: Emitting a message to the fedmsg bus.
To ssh://kenhys@pkgs.fedoraproject.org/groonga
   ee49528..8e64aaf  master -> master

masterのパッケージをビルドする

リポジトリへpushした後、パッケージをFedoraのビルドサーバーでビルドします。ビルドには以下のコマンドを実行します。

$ fedpkg build

リモートのビルドサーバーでビルドしているので、それなりに時間がかかります。masterでの作業はこれでおしまいです。

次はmasterの変更を別のブランチへマージします。

f19ブランチでパッケージをコミットする

masterでパッケージのビルドまで終わったら、今度はその変更をFedora 19向けにも反映します。そのためには作業するブランチを以下のようにしてmasterからf19ブランチへと切り替えます。

$ fedpkg switch-branch f19

masterから変更点をマージして、リポジトリへとpushするには以下のコマンドを実行します。

$ git merge master
$ git push

f19ブランチでパッケージをビルドする

masterと同様にして、Fedora 19向けにパッケージをビルドします。そのためには以下のコマンドを実行します。

$ fedpkg build

これで、Fedora 19向けのリリースパッケージをビルドできました。

f19ブランチでパッケージをアップデートする

ビルド済みのリリース用パッケージをBohdi経由で配布できるようにします。そのためには以下のコマンドを実行します。

$ fedpkg update

このとき、アップデート情報を入力します。今回はバグフィックスリリースなので、typeをbugfixにして、notesには更新理由を書きます。

Creating a new update for  groonga-3.0.4-1.fc19 
Password for kenhys: 
Creating a new update for  groonga-3.0.4-1.fc19 
Update successfully created
================================================================================
     groonga-3.0.4-1.fc19
================================================================================
    Release: Fedora 19
     Status: pending
       Type: bugfix
      Karma: 0
    Request: testing
      Notes: Update to 3.0.4. See changes at
           : http://groonga.org/docs/news.html#release-3-0-4-2013-0
           : 5-29
  Submitter: kenhys
  Submitted: 2013-05-29 06:37:33
   Comments: bodhi - 2013-05-29 06:37:36 (karma 0)
             This update has been submitted for testing by kenhys.

  https://admin.fedoraproject.org/updates/groonga-3.0.4-1.fc19

これで、f19ブランチでの作業はおしまいです。次はf18ブランチを更新します。

f18ブランチでパッケージをコミットする

Fedora 19のときと同様に作業ブランチを切り替えます。

$ fedpkg switch-branch f18

Fedora 19のときと同様にmasterの変更点をf18ブランチへとマージ、リポジトリへpushします。

$ git merge master
$ git push

f18ブランチでパッケージをビルドする

Fedora 19のときと同様にパッケージをビルドします。

$ fedpkg build

f18ブランチでパッケージをアップデートする

Fedora 19のときと同様にパッケージをBohdi経由で配布できるようにします。

$ fedpkg update

これで、f18ブランチでの作業はお終いです。

ブランチごとの作業まとめ

ここまでで、master、f19、f18と三つのブランチで作業しました。

それぞれのブランチで必要な作業を以下にまとめます。

作業	masterブランチ	Fedora 19ブランチ	Fedora 18ブランチ
新規リリースの取り込み	必要	不要	不要
パッケージのコミット	必要	必要	必要
パッケージのビルド	必要	必要	必要
パッケージのアップデート	不要	必要	必要
パッケージのテスト	不要	必要	必要
パッケージのリリース	不要	必要	必要

まず、masterで「新規リリースの取り込み」から「パッケージのビルド」まで行いました。次にfedpkg switch-branch f19でFedora 19のブランチに切り替えmasterブランチからマージした後、「パッケージのコミット」から「パッケージのアップデート」まで行いました。同様にして、fedpkg switch-branch f18でFedora 18のブランチに切り替えmasterブランチからマージした後、「パッケージのコミット」から「パッケージのアップデート」まで行いました。

上記を具体的な実行コマンド列で比較すると以下のようになります。

masterブランチの場合

$ fedpkg new-sources groonga-3.0.4.tar.gz
$ fedpkg commit
$ git push
$ fedpkg build

Fedora 19ブランチの場合

$ fedpkg switch-branch f19
$ git merge master
$ git push
$ fedpkg build
$ fedpkg update

Fedora 18ブランチの場合

$ fedpkg switch-branch f18
$ git merge master
$ git push
$ fedpkg build
$ fedpkg update

ここまでの作業がブランチごとに完了したら、次のステップ「パッケージのテスト」へと進みます。

パッケージのテスト

fedpkg updateまで終わったら、あとは新規パッケージを登録したときと同様にtestingリポジトリでフィードバックを待ちます。詳しくは「Fedoraプロジェクトで新規パッケージをリリースする方法」の「パッケージのテスト」を参照してください。

パッケージのリリース

testingリポジトリで一定期間が経過するとパッケージをリリースすることができます⁴。Bohdiのインターフェースから一般ユーザーが利用しているyumリポジトリへとパッケージを反映します。詳しくは「Fedoraプロジェクトで新規パッケージをリリースする方法」の「パッケージのリリース」を参照してください。

まとめ

今回はFedoraプロジェクトで既存パッケージを更新する方法を紹介しました。パッケージは一度登録したらそれで終わりではありません。アップストリームで新規リリースがあれば、それに対応していく必要があります。継続してメンテナンスしていくことはとても重要です。

Fedoraプロジェクトでパッケージをメンテナンスすることになったら参考にしてみてください。

当時3.0.2がgroonga.orgの独自リポジトリでリリースされていたものの、Fedoraプロジェクトでは2.0.9のままになっていた。 ↩
パッケージのメンテナンスに用いるアカウント。https://admin.fedoraproject.org/accounts/にて登録する。 ↩
rawhideとも呼ばれるブランチ。 ↩
フィードバックで問題なしとされた場合は自動的に一般ユーザ向けyumリポジトリへと反映されます。 ↩

ククログ