openSUSE:Build Service チュートリアル
目次
事前準備
下記をお読みになるにあたっては、 RPM や RPM の作成方法について、一般的な理解があるものとします。 openSUSE については パッケージングガイドライン を、他のディストリビューションについては、対応するパッケージングシステム (たとえば Debian であれば dpkg) のドキュメンテーションをお読みください。この文書は、パッケージングに関する文書を置き換えるものではありません。それらの情報は上記のリンク先をお読みください。
また、お使いのプロジェクト内のパッケージにおけるソースコードの構造についても、詳しく知っておく必要があります。 Build Service にはよくある間違いを回避する機能や、構築失敗時のガイド機能なども用意されています。ヘルプやアドバイスをご希望の場合は、 buildservice メーリングリスト (英語) にてお願いいたします。ただし、どのパッチを適用すべきかやどのようにコンパイラのフラグを設定すべきかなどについては、必ずご自身で判断してください。
要件
まず、 Build Service を利用するには、 openSUSE/SUSE アカウントでのログイン が必要となります。このアカウントは wiki や Bugzilla でも共通に利用できる仕組みですが、お持ちでない場合は Build Service のページ右上にある "sign up" リンクから作成することができます。なお、パスワードを変更した際は ~/.oscrc ファイルもそれに合わせて変更する必要があることに注意してください。 osc コマンドではこのファイルを利用してログインを行なうため、パスワードが合っていないとコマンドの実行が失敗するほか、何度も失敗するようであれば、アカウントがブロックされる場合もあります。
これに加えて、構築処理を一般ユーザで開始する場合 (特に理由のない限り、一般ユーザでの構築をお勧めします) 、ローカルマシンの root パスワードを尋ねられる場合があります。このような場合は、下記の手順に従って /etc/sudoers 内にユーザを追加することで、パスワードの入力を省略することができます:
- 設定ファイル ~/.oscrc を開く
- 下記の行を追加して保存する:
su-wrapper = sudo
- 下記のコマンドを実行する:
sudo /usr/sbin/visudo
- 下記の行を追加する (なお、 LOGIN は自分のユーザ名に置き換える):
LOGIN ALL = NOPASSWD: /usr/bin/build LOGIN ALL = NOPASSWD: /usr/bin/osc
使用する用語
Build Service には プロジェクト (プロジェクトの一覧) と呼ばれるまとまりがあり、そのプロジェクトの中に 1 つ以上の パッケージ (RPM/DEB など) が含まれています。パッケージには、ソースコードのアーカイブやパッチファイル、 spec ファイルなどが含まれています。プロジェクトの出力結果は リポジトリ と呼ばれ、生成された RPM (DEB) ファイルとそのディレクトリ構造のほか、 zypper のようなツールから検索や解決ができるようにするためのインデックスやメタデータなども含まれています。リポジトリは、オペレーティングシステムのバージョン (たとえば openSUSE 11.2) ごとに作成されます。
Build Service には "公式の" openSUSE プロジェクトも存在していて、こちらで標準の openSUSE ディストリビューションを作成しています。 "Factory" プロジェクトとは作業途中のものを含めるためのプロジェクトで、次期 openSUSE バージョンを作成するために用意されています。また、 Apache や network:telephony などのように、特定の分野に特化した多数のプロジェクトが用意されています。また、各ユーザは自分専用の "作業領域" として、 home:ユーザ名 というプロジェクト (home プロジェクト) を持っています。
RPM は一般に、他の RPM との依存関係を多数持つように構成されています。これらの依存先の RPM は、 Build Service 内の他のプロジェクトが提供するものである場合もあります。このことは、下記 2 つの意味を含むことになります。
まず 1 つめに、お使いのパッケージを実行する際に他のパッケージを必要とする場合 ("Requires") 、構築時にも必要となる場合がある (つまり "BuildRequires") ことを意味します。 Build Service には、依存関係を自動的に検索して解決するような仕組みは用意されていません (ただし標準のディストリビューションに含まれていないものの場合のみ) 。そのため、何らかの方法で Build Service に対して、必要なパッケージの取得元を指定する必要があります。
2 つめに、リポジトリは できる限り閉じる ことを目指すべきであることを意味します。言い換えると、リポジトリ内の任意のパッケージの依存関係は、その中で閉じるべき (ただし標準のディストリビューションに含まれるパッケージは除きます) であることになります。依存関係をリポジトリ内でとじることで、そのプロジェクトが提供する RPM をインストールする際、より簡単に実施できることになります。ただし、これは必須ではありません。ユーザは 検索インターフェイス を利用して依存関係を手作業で探すことができるからです。
Build Service では、いくつかの方法でこれらの依存関係を処理することができます。
1 つめの方法としては、お使いのリポジトリに必要なパッケージを直接追加してしまう、というやり方があります。これは特に、他のプロジェクトで必要なパッケージを提供していないような場合に有用な方法ですが、一般的には他のプロジェクトで提供されている場合が多いので、できるだけそれらの成果を再利用するようにしてください。
2 つめの方法としては、他のプロジェクトのリポジトリを、お使いのリポジトリ内にリンクするやり方があります。これは 階層化 (layering) と呼ばれる方式で、プロジェクトのメタデータを編集し、他のプロジェクトやリポジトリを追加して実現することになります。このように設定することで、 Build Service は構築処理時にそれらのプロジェクトやリポジトリ内を検索し、 "BuildRequires" で指定したパッケージを取得するようになります。これによりパッケージの構築は成功するようになりますし、問題の解決にもつながりますが、上述の "できる限り閉じる" 目的は全く達成できません。ユーザは必要なパッケージを自分自身で探してインストールする必要があることになってしまいます。しかしながら、ユーザが両方のリポジトリの存在に気付くように構成されていれば、よい選択肢であるといえます。
3 つめの方法としては、 リンク を作成するやり方があります。これは他のプロジェクト内に存在するパッケージを再利用するための方法で、依存するパッケージを構築してお使いのリポジトリ内で公開することができるようになります。これにより、作業を重複させることなく、かつ "できる限り閉じる" 目的を達成できるようになります。
リンクの方法には 2 つのタイプがあります。 1 つは単純な リンク で、もう 1 つは アグリゲート と呼ばれるものです。 リンク を実施した場合はパッケージの構築方法を修正することができるほか、パッチを追加したり追加のリポジトリを設定したりすることもできます。なお、生成されるパッケージの RPM には、元のプロジェクトとは異なるビルド番号が付与されます。このことにより、ユーザはバージョン番号で混乱する (どちらが新しいものなのかがわからなくなる) ことが考えられますので、あらかじめご注意ください。
必要なパッケージを修正する必要がない場合は、 リンク ではなく アグリゲート を使用するのがよいでしょう。 アグリゲート は "読み込み専用の" リンクとも呼ばれ、お使いのプロジェクト内でパッケージを構築する代わりに、元のプロジェクトから構築済みのパッケージをコピーします。そのため、両方のプロジェクト内で同一の RPM (ビルド番号も同じ) が提供されることになります。ユーザにとっては、 RPM が同一であることから、混乱を防ぐことにもつながります。
Build Service ではリンクされたパッケージの変更を自動的に検出して、必要であれば再構築を実施します。
作業の流れ
下記の作業手順は、プロジェクトを作成したパッケージを追加する際に実施する、通常の流れです。実際の作業では、下記に加えていくつかの追加作業を実施することになるほか、構築が失敗した際は繰り返し実施する必要がある場合もあります。下記の手順は、あくまでも達成までの流れをつかんでいただくためのものです。
下記の流れでは、主に 2 つの方法による手順を説明します:
- Web クライアント を使用する方法
- コマンドライン クライアントを使用する方法
- もう 1 つの方法として MonoOSC というクライアントを使用する方法もあります。 MonoOSC については こちら をお読みください。
ステップ 1 - ログインと (初回ログイン時の) ローカルプロジェクトの設定
既に openSUSE のアカウントをお持ちであれば、話は簡単です。お持ちでない場合は、あらかじめ作成しておいてください。
- Web クライアント の場合: http://build.opensuse.org/ を開いてから、右上にある Log In リンクを選択してログインします。ログインが完了したあとは、ユーザ名を選択すると自分の home プロジェクトに移動することができます。
- コマンドライン の場合: 何よりも先に、お使いのマシンにコマンドラインクライアントをインストールします。 openSUSE-Tools ソフトウエアダウンロードリポジトリには、さまざまなディストリビューション向けの osc パッケージ (もちろんこれも、 Build Service のプロジェクトで構築されたものです) が用意されています。あとはいつものパッケージマネージャで osc をインストールしてください。
インストールが完了したら、プロジェクトのファイルを保存しておくためのディレクトリに cd します。 osc はよく知られている SVN に似たコマンド体系になっていますので、こちらを使ったことがあれば、 osc も問題なく使いこなすことができます。たとえば home プロジェクトをチェックアウトしたい場合は、下記のように実行します:
cd <プロジェクトのファイルを保存しておくためのディレクトリ> osc checkout home:<ユーザ名> cd home:<ユーザ名>
- (なお、 <ユーザ名> はお使いのユーザ名に置き換えてください)
osc を起動すると、まず ユーザ名とパスワード の入力を促されます。入力を行なうと、その情報をもとに Build Service にアクセスして、 home プロジェクトをチェックアウトします。チェックアウトの際には、プロジェクト名でディレクトリが作成 (home:<ユーザ名>) されます。ここで入力した設定は ~/.oscrc ファイルを編集して変更することができます。
ステップ 2 - パッケージの作成とアップロード
home プロジェクトは "作業場" として使うことのできるプロジェクトで、パッケージが問題なく動作して適切なプロジェクトに移動するまでの間、パッケージをテストする場所として使用することができます。
- Web クライアント の場合: 右側にある "Home Project" のリンクを選択することで、 home プロジェクトに移動することができます。ここから "packages" タブにある "create new package" (パッケージの作成) を選択してください。その後、合わせて 3 つの項目に対して、必要な情報を入力します。 "Name" にはパッケージの名前 (必須) を、 "Title" と "Description" にはパッケージのタイトルと説明をそれぞれ入力します。
- パッケージを作成したら、 "Sources" タブを選択してパッケージ内にファイルを追加していきます。少なくとも、 spec ファイルとパッケージのソースコードをアップロードする必要があります (パッケージングガイドライン もお読みください)
- コマンドライン の場合:
osc meta pkg -e home:<ユーザ名> <パッケージ名>
上記を実行すると、ひな型となる XML ファイルを編集するべくエディタを起動します (EDITOR 環境変数で指定しているエディタを起動します) 。 XML ファイルで入力する内容は、 Web クライアントでの内容 (名前, タイトル, 説明) と同じです。
あとは下記を実行することで、新しいパッケージを表す新しいディレクトリを取得することができます:
osc up home:<ユーザ名>
コマンドラインでファイルを追加するには、作成された新しいディレクトリに移動して、必要なファイルをコピーします (a.tar.xz などのファイルを配置します) 。
openSUSE の RPM パッケージの場合、 spec ファイルで構築手順を指定します。 spec ファイルの作成方法については パッケージングガイドライン をお読みください。手短に始めたい場合は、類似のパッケージを構築する際に使用している spec ファイルを流用したり、ソースコードの tar ボールに付属している spec ファイルを使用したり (もしあれば) するのがよいでしょう。
必要なファイルをすべて追加したら、下記を実行してアップロードするようにマーキングを設定します:
osc add *
上記はディレクトリ内にあるすべてのファイルを、次回のコミットで送信するコマンドです。コミットは下記のようにして行ないます:
osc commit
コミットを実行すると、自動的に構築処理が始まります。なお、ローカルでのパッケージ構築がうまくいってからコミットしたいような場合は、 ローカルでのパッケージ構築 をお読みください。
ステップ 3 - ビルドターゲットの選択
次に、パッケージをどのディストリビューション (例: openSUSE 13.1, Ubuntu 14.04 など) に対して構築するかを選択します。
- Web クライアント の場合: プロジェクト内の "Repositories" タブに切り替えて、 Add repositories を選択して、利用可能なディストリビューションやアーキテクチャの中から選択します。
- コマンドライン の場合: まずは利用可能なリポジトリの一覧を取得します。下記のように実行します:
osc ls
取得したら、メタデータを編集します:
osc meta prj -e home:<ユーザ名>
エディタが起動したら、下記のような行を追加します:
<repository name="openSUSE_Factory"> <path project="openSUSE:Factory" repository="standard" /> <arch>x86_64</arch> <arch>i586</arch> </repository>
project には openSUSE:Factory, openSUSE:13.1, SUSE:SLE-11:SP3 などのような名前を指定します。 repository="standard" は、将来の拡張で使用される予定の項目です (リポジトリの分割 (フォーク) 処理で使用します) 。
ステップ 4 - パッケージの構築
コミットまたはファイルの変更を行なうと、自動的にパッケージの構築のスケジュールが設定されます。また、必要としているパッケージが何らかの理由で再構築された際も、お使いのパッケージは自動的に再構築されます。
手動で再構築を開始したい場合は、下記のように実行します:
osc rebuildpac <プロジェクト名> <パッケージ名> [<リポジトリ> [<アーキテクチャ>]]
<リポジトリ> と <アーキテクチャ> の項目は任意指定で、特定のリポジトリやアーキテクチャに限定して再構築させたい場合に使用します。
お使いのプロジェクトの名前が home:username という名前であるとすると、 http://download.opensuse.org/repositories/home:/username/ という URL から構築済みのパッケージにアクセスすることができます。
ローカルでのパッケージ構築
場合によっては、 Build Service での構築完了を待つよりも、ローカルのマシンでパッケージを構築してテストしたほうが簡単であることがあります。 そのような場合に対応するため、 osc はローカルでのパッケージ構築を行なうことができます。ただし、お使いのハードウエアで対応している場合に限られます (たとえば x86_64 のマシンでは i586, x86_64 の両方を構築することができますが、 i586 のマシンでは i586 のみを構築することができます) 。
最新のソースコードを取得していることの確認
まずは osc checkout (osc co) または osc up を実行して、最新のソースを取得していることをご確認ください。
具体的には、下記のように実行します:
cd <OBS 作業用のディレクトリ>; osc co <プロジェクト名> <パッケージ名>
または
cd <OBS 作業用のディレクトリ>/<プロジェクト名>; osc co <パッケージ名>
または
cd <OBS 作業用のディレクトリ>/<プロジェクト名>/<パッケージ名>; osc up
ローカルでの構築の実施
osc build <プラットフォーム> <アーキテクチャ> <spec ファイル名> [--clean|--noinit]
たとえば下記のように実行します:
~/obs/home:user/project # osc build openSUSE_11.4 x86_64 project.spec
上記を実行すると、 osc は OBS のリポジトリサーバに接続して、必要な RPM をキャッシュディレクトリ /var/tmp/osbuild-packagecache/プラットフォーム/リポジトリ/アーキテクチャ にダウンロードします。ネットワークの帯域消費を削減したい場合は、 DVD や iso ファイルを利用して、必要な RPM をキャッシュディレクトリにコピーしておくことをお勧めします。
たとえば openSUSE_12.1 の RPM を DVD iso からコピーするには、下記のように実行します:
mount openSUSE-12.1.iso /mnt/ -o loop mkdir -p /var/tmp/osbuild-packagecache/openSUSE\:12.1/standard cp -r /mnt/suse/* /var/tmp/osbuild-packagecache/openSUSE:12.1/standard
なお、 DVD からファイルをコピーした場合は、それらに書き込むことができなくなってしまいますが、 osc はキャッシュ内にデータを書き込む必要がありますので、下記のようにして書き込むことができるようにします:
find /var/tmp/osbuild-packagecache/openSUSE:12.1 -type d -exec chmod 755 {} +
find /var/tmp/osbuild-packagecache/openSUSE:12.1 -type f -exec chmod 644 {} +
あとは下記のように実行すれば、パッケージを構築することができます:
osc build openSUSE_12.1 i586 <some-package-name>.spec
osc は /var/tmp/build-root/ 内に chroot 完了を作成し、その中でパッケージの構築を開始します。ソースコードのごく一部だけを変更したような場合で、構築環境を再作成しないようにしたい場合は、 --noinit オプションを指定してください。また逆に、 chroot 環境が壊れてしまっていると思われる場合は、 --clean で再作成することもできます。なお、 chroot ディレクトリの場所を変更することもできます。詳しくは ~/.oscrc ファイル内のコメントをお読みください。
sudo rpm --import - <<_END_KEY $(osc signkey 鍵を取り込むプロジェクト名) _END_KEY
この chroot 環境でパッケージが構築することができると、パッケージは /var/tmp/build-root/home/abuild/rpmbuild/RPMS/ (古いバージョンの rpmbuild の場合は、 /usr/src/packages/RPMS/ でした) に保存されます。
なお、お使いのパッケージが URL ダウンロードサービスを使用している場合、下記のコマンドを実行しなければならないかもしれません:
zypper ar -r http://download.opensuse.org/repositories/openSUSE:/Tools/openSUSE_11.3/openSUSE:Tools.repo
ローカルでの構築結果は、 /var/tmp/build-root/.build.log にログが記録されています。
ローカルの構築処理におけるエラーの修正
openSUSE やその他のディストリビューションに対して新しいパッケージを構築したい理由は、お使いのパッケージがまだ自分のオペレーティングシステムのバージョンやリリースに対して構築されていないから、ということが多いでしょう。 しかしながら、構築処理を実施することで、修正する必要のあるさまざまな新しいエラーに直面することにもなります。 エラーを修正するための最も簡単な方法は、構築環境内に chroot して、そこで修正を作成する方法です。 X11 にアクセスしたい場合や必要なディレクトリをマウントしたい場合は、 chroot の代わりに openroot を利用してもかまいません。
osc chroot openSUSE_12.1 x86_64
古いやり方では、下記のようにします:
chroot /var/tmp/build-root/ cd /home/abuild/rpmbuild/BUILD/your-package-dir ls
もしくは:
openroot /var/tmp/build-root/ 'cd /home/abuild/rpmbuild/ILD/your-package-dir; ls; bash' ... exit
依存関係
構築時に依存関係 (dependency) のエラーが発生した場合は、下記のように行を追加して依存関係を解決します:
BuildRequires: cmake libkde4-devel
上記の例では、パッケージを構築する前に cmake と libkde4-devel をインストールします。
buildroot への追加パッケージのインストール
デバッグ用の目的で、 buildroot に追加のパッケージをインストールして調査を行ない、問題を解決したい場合があります。このような場合は、 ~/.oscrc ファイルの extra-pkgs に必要なパッケージを指定してください。たとえば下記のようになります:
extra-pkgs = vim gdb strace valgrind
インストールの権限
たとえば下記のようなエラーメッセージが発生したとします:
error: Bad exit status from /var/tmp/rpm-tmp.qrRAn2 (%install)
これは %install ステップで何らかのエラーが発生した (それまでのステップは成功していた) ことを示しています。上記のようなエラーは、主に間違った場所にインストールを行なおうとしている場合に発生します。このような場合は、 spec ファイル内の make install コマンドで下記のように指定してください:
make install DESTDIR=%buildroot
OBS への作業結果の送信
<パッケージ名> のディレクトリ内にあるファイルが想定通りに動作することが確認できたら、あとは OBS に対して作業結果を送信するだけです。
パッケージに対してファイルを追加するには:
osc add
パッケージからファイルを削除するには:
osc rm
changes ファイル (*.changes) を更新するには:
osc vc
更新したファイルを OBS に送信するには:
osc commit
パッチ (修正)
新しいパッチを作成するには、いくつかの方法があります。たとえばシンプルなツールである diff や、高度なツールである quilt を利用して作成することもできます。パッチについて、詳しくは パッチガイドライン をお読みください。
diff の使用
あるファイルに対するパッチを作成したい場合は、まず元のファイルを .orig などにコピーしてから編集してください。あとは構築がうまくいくまでファイルの編集を繰り返して、最後にパッチを作成します。
なお、構築処理時により詳しく出力させたい場合は、 spec ファイル内に set -x を挿入してください。これにより、 bash が実行したコマンドをすべて出力するようになります (set +x で出力を停止することができます) 。
diff -Pdpru /var/tmp/build-root/home/abuild/rpmbuild/BUILD/your-package-dir/Makefile.orig \
/var/tmp/build-root/home/abuild/rpmbuild/BUILD/your-package-dir/Makefile \
>/osc/home:user/your-package-dir/my.patch
あとは spec ファイルのヘッダ部分に Patch67: my.patch (ここで 67 には、他と重複しない最も小さい番号を指定します) のように指定して、パッチを追加します。また、適切な場所 (通常は %setup) の適切な位置に %patch67 -p7 のように指定して、パッチを適用するように指定します (ここで -p7 は、パッチファイル内に記されたディレクトリ構造のうち 7 つ分を無視するようにする予定です) 。
quilt の使用
quilt のような自動パッチ生成プログラムを利用すると、より簡単に実現することができます:
osc co プロジェクト名/パッケージ名
cd プロジェクト名/パッケージ名
quilt setup -v *spec
cd パッケージ名-*/
quilt push -a # 古いパッチの適用
quilt new パッケージ名-バージョン_fixbuild.patch
quilt edit src/foo.c
quilt refresh
上記を実行すると、 foo-fixbuild.patch ファイルが親ディレクトリ内に自動的に作成されます。それまでパッチを全く含んでいなかったパッケージの場合は、パッチのディレクトリからお使いのパッケージのディレクトリに、忘れずにファイルをコピーしてください。あとは quilt setup を再実行すると、初期のパッチを取得することができます。パッチを作業用のコピーから削除したい場合は、 quilt pop を使用します。
なお .quiltrc ファイルの例は下記のとおりです:
# Options passed to GNU diff when generating patches
QUILT_DIFF_OPTS="--show-c-function"
# QUILT_DIFF_OPTS=""
# Options passed to GNU patch when applying patches
#QUILT_PATCH_OPTS="--ignore-whitespace --unified-reject"
# Options to pass to commands (QUILT_${COMMAND}_ARGS)
QUILT_PUSH_ARGS="--color=auto"
QUILT_DIFF_ARGS="--color=auto"
QUILT_REFRESH_ARGS="--backup -p0"
QUILT_PATCH_OPTS="--unified-reject-files --backup"
ステップ 5 - ログファイルの確認
Build Service では、それぞれのパッケージ構築に対して 1 つの巨大なログファイルを生成します。
- Web クライアント の場合: パッケージを表示させている状態から、 Build result タブを選択すると構築結果がわかります。
- コマンドライン の場合: 必要に応じて、いくつかの方法があります (パッケージのディレクトリ内にいる場合は、
プロジェクト名とパッケージ名の指定は不要です:
osc prjresults [<プロジェクト名>]
上記を実行すると、プロジェクト全体での構築結果をひょうじすることができます。また、下記のように実行すると、個別のパッケージに対する構築結果を表示することができます:
osc results [<プロジェクト名> <パッケージ名>]
また、下記のように実行すると、パッケージ構築時のログファイルを表示することができます (パッケージのディレクトリ内にいる費用があります):
osc buildlog <プラットフォーム> <アーキテクチャ>
パターンの作成
パターンとは、パッケージの一覧と用途などの説明が含まれているファイル群のことを指します。 Build Service では、これに加えて生成したリポジトリごとに .ymp というファイルを作成します。生成した .ymp ファイルは、ユーザから 1 クリックインストール の際に使用することができます。
手短にいうと、パターンはパッケージ間の依存関係に悩まされることなく、一般的に必要とされる複数のソフトウエアをインストールする際に便利な仕組みです。
パターンの送信は、 API を直接呼び出すか、 osc を利用して行なうことができます:
- $EDITOR 内でパターンを開くには (存在していない場合は作成されます):
osc meta pattern -e <プロジェクト名> <パターン>
- 既存のパターンを一覧表示するには:
osc meta pattern <プロジェクト名>
- 既存のパターンを取得するには:
osc meta pattern <プロジェクト名> <パターン>
- ローカルファイルを送信してパターンを作成するには:
osc meta pattern --file <ローカルファイル> <プロジェクト名> <パターン>
パターンをテストしたい場合は、 .ymp ファイルを Konqueror で開くと、インストーラを起動することができます。 Konqueror をインストールしていない場合は、下記のようにして一般ユーザからコマンドを起動します:
/sbin/yast2 MetaPackageHandler http://download.opensuse.org/repositories/<プロジェクト名>/<SUSE_Factory または openSUSE_10.2>/<パターン名>.ymp
下記は KDE:KDE4 プロジェクトが提供しているパターンファイルの例です。生成された .ymp ファイルは、 こちら からアクセスすることができます。
<pattern
xmlns="http://novell.com/package/metadata/suse/pattern"
xmlns:rpm="http://linux.duke.edu/metadata/rpm"
>
<name>KDE 4 Games</name>
<summary>KDE 4 Games</summary>
<description>A number of games for KDE 4.</description>
<uservisible/>
<category lang="en">Desktop Functions</category>
<rpm:recommends>
<rpm:entry name="kde4-kpat"/>
<rpm:entry name="kde4-kmahjongg"/>
<rpm:entry name="kde4-kmines"/>
<rpm:entry name="kde4-kreversi"/>
<rpm:entry name="kde4-ksudoku"/>
</rpm:recommends>
<rpm:suggests>
<rpm:entry name="kde4-katomic"/>
<rpm:entry name="kde4-kbattleship"/>
<rpm:entry name="kde4-ksquares"/>
<rpm:entry name="kde4-bovo"/>
<rpm:entry name="kde4-kiriki"/>
<rpm:entry name="kde4-kwin4"/>
<rpm:entry name="kde4-kolf"/>
<rpm:entry name="kde4-klines"/>
<rpm:entry name="kde4-ksame"/>
<rpm:entry name="kde4-lskat"/>
<rpm:entry name="kde4-kgoldrunner"/>
<rpm:entry name="kde4-kblackbox"/>
<rpm:entry name="kde4-kbounce"/>
<rpm:entry name="kde4-ktuberling"/>
<rpm:entry name="kde4-knetwalk"/>
<rpm:entry name="kde4-kjumpingcube"/>
<rpm:entry name="kde4-kspaceduel"/>
<rpm:entry name="kde4-konquest"/>
<rpm:entry name="kde4-kshisen"/>
</rpm:suggests>
</pattern>
いくつかのタグの説明:
| タグ | 説明 |
|---|---|
<rpm:requires> <rpm:entry name="example" /> </rpm:requires> |
example パッケージを 必要とする 例: ここで指定したパッケージは、必ずインストールしなければなりません - インストールしないと、パターンをインストールすることができなくなります。 |
<rpm:recommends> <rpm:entry name="example" /> </rpm:recommends> |
example パッケージを 推奨している 例: ここで指定したパッケージが利用可能であり、このパッケージの依存関係が満たされていれば、パッケージをインストールします。パッケージが利用できない場合でも、エラーメッセージにはなりません。依存関係が満たされていない場合は、パッケージが表示されますがインストールは行なわれません。 |
<rpm:suggests> <rpm:entry name="example" /> </rpm:suggests> |
example パッケージを 提案している 例: パターン内に表示されますが、既定ではインストールされません。 |
簡単な変更を行なう際の作業例
本章では、チュートリアルとして利用できるような具体的な例を示しています。
|
警告!
|
ドラフト版 (未完成、要レビュー) です |
一般的には、既存のプロジェクト内にある既存のパッケージを分岐 (ブランチ) して、必要な変更を実施したあと、元のパッケージに変更点を送信する流れになります。
基本的な手順は下記のとおりです:
- オリジナルのパッケージ (以下 元パッケージ) からの分岐 (ブランチ): osc branch <元プロジェクト名> <元パッケージ名> を実行して、新しい分岐プロジェクト home:<ユーザ名>:branches:<元プロジェクト名> を作成します。元と同じ名前のパッケージがその中に作成され、内容がコピーされます。
- 分岐したパッケージのチェックアウト: osc checkout home:<ユーザ名>:branches:<元プロジェクト名>/<元パッケージ名> を実行すると、サーバからローカルのディレクトリに対して、分岐したパッケージをダウンロードします。その際、 home:<ユーザ名>:branches:<元プロジェクト名>/<元パッケージ名> というディレクトリを作成します。
- ローカルのサブディレクトリへの移動: cd home:<ユーザ名>:branches:<元プロジェクト名>/<元パッケージ名> を実行して、通常のデフォルトの umask 値を umask 0022 のように実行して適用します。
- パッケージのローカルコピーに対して、必要な変更が完了するまで下記を繰り返し実施します:
- ソースファイルに対して必要な変更を実施する (たとえば spec ファイルを編集したり、パッチを作成したりする)
- ローカルでの構築を実施する
- ローカルで構築したパッケージをインストールする
- インストールしたパッケージをテストする
- changes ファイルの更新: osc vc を実行するとエディタ (通常は 'vi') を起動し、 RPM の changes 項目を作成するためのヘッダが書き込まれます。ここに実施した変更内容を英語で記述します。バグ報告からの修正である場合は、 bnc#123456 のようにバグへの参照情報を記載します。
- 新しいファイル (パッチファイルなど) を追加した場合や、ファイルを削除した (たとえば古いパッチを削除した) 場合は、ローカルのソースファイルに対する制御情報を更新します: osc addremove を実行してから osc status を実行して、 '?' や '!' の状態になっているファイル (osc の制御下にないファイル、および osc で制御しているものの、存在しないファイル) が無いようにします。
- ローカルのソースファイルからの分岐したパッケージへの送信: osc commit を実行すると、ローカルにあるソースファイルをサーバの分岐したパッケージにアップロードします。これにより、分岐したパッケージは自動的に再構築されるようになります。
- 元のパッケージで有効化されていたすべてのリポジトリに対して、構築結果を確認します: osc results --verbose home:<ユーザ名>:branches:<元プロジェクト名> <元パッケージ名> 元のパッケージで有効化されていたすべてのリポジトリと、その構築結果を一覧で表示するには、下記のように実行します: osc results <元プロジェクト> <元パッケージ>
- 元のパッケージで有効化されていたすべてのリポジトリに対して、分岐したパッケージの再構築が "成功" した場合は、下記のように実行して変更を元のパッケージに送信するよう要求を作成します: osc submitrequest --message='<変更点の概要説明 (英語) (バグ報告からの修正である場合は、 bnc#123456 のようにバグへの参照情報を記載します)>' home:<ユーザ名>:branches:<元プロジェクト名> <元パッケージ名> <元プロジェクト名> <元パッケージ名> 。要求を作成したあとは、表示されるリクエスト ID 番号を覚えておきます。
- しばらくした後、作成した要求がどのように処理されているのかを確認します: osc request show <リクエスト ID 番号> 。なお、元のパッケージのメンテナンス担当者に対して、直接連絡を取りたい場合は、下記のように実行します: osc maintainer <元プロジェクト> <元パッケージ> 。これにより、まずユーザ名が表示されますので、さらに下記を実行してフルネームと電子メールアドレスを取得します: osc whois <ユーザ名>
上記は少し複雑な手順ではありますが、一度理解してしまえば自然に使いこなせるでしょう。
なお、上記の手順は、 OBS 内に既にアカウントをお持ちである場合を前提にしています。お持ちでない場合は http://build.opensuse.org/ にアクセスして、右上にある "Sign Up" のリンクから登録したあと、ログインしてください。なお、 OBS は openSUSE インフラストラクチャの他のシステム (たとえば Bugzilla) と共通の認証システムを使用していますので、それらを使用したことがあれば、その際に使用したアカウントでログインしてください。初めて OBS にログインすると、 home プロジェクトが自動的に作成されます。
下記は実際の例です:
コマンドラインから一度だけ実行する必要がある、セットアップ:
sudo zypper in osc mkdir ~/obs
分岐パッケージを作成してパッケージのローカルコピーを作成する:
cd ~/obs umask 0022 osc branch security sleuthkit osc co home:<your_user_name>:branches:security/sleuthkit cd ~/obs/home:<your_user_name>:branches:security/sleuthkit
これでローカルにパッケージを持ってくることができました。あとは下記のように実行します:
# tar ボールを展開していくつかの処理を行ないます quilt setup sleuthkit.spec # ソースコードのディレクトリに移動します cd sleuthkit-3.2.3 # すべてのパッチを適用します quilt push -a # 新しいパッチを適用します quilt new testing.patch # パッチにファイルを追加します quilt add <ファイル名> vi <ファイル名> # もしくは、下記のように実行することもできます: quilt edit <some-file> # 最後は下記のように実行します quilt refresh -p1 # パッチをプロジェクトのディレクトリにコピーします cp patches/testing.patch .. # あとは spec ファイルを編集します cd .. vi sleuthkit.spec # ヘッダ領域内に "Patch0" などの形でパッチを追加するとともに、 %prep のセクションで %patch0 -p1 のように適用するようにします # OBS に対してパッチファイルを追加します osc add testing.patch # changes ファイルを更新します osc vc -m "Fix some typos." # 下記のようにして構築したあとは、インストールしてテストします osc build # ローカルでインストールをテストします。 osc build を実行すると、最後に RPM のフルパスが表示されるので、そこに表示されたパスを指定してください zypper in -f <RPM のフルパス> # うまく動作すれば下へ、うまく動作しない場合は quilt edit に戻ってやり直します # OBS に編集結果を送信します osc commit # OBS で新しいパッケージが更新されるまで、しばらく待ちます # Web UI などで構築状態を確認し、 # 問題なく公開 (publish) までたどり着けていれば、 OBS から RPM を取得して # 再度テストを実施します。問題がなければ元のパッケージに変更点を送信します。 # Bugzilla のバグ報告から修正したものであれば、その参照情報を添付してください。