Package maintenance guide/ja

In other languages: English (en) 中文（中国大陆） (zh-cn) 日本語 (ja) português do Brasil (pt-br) [edit]

このページでは、gitベースのFedoraのパッケージ保守管理システムの、日常的に行う基本操作を説明しています。主な対象読者は、新規、及び、既存のFedoraのパッケージ保守管理者です。しかし、簡単に匿名かつ読み取り専用でのシステムの利用も含んでいます。このガイドは、RPMパッケージングガイドではありません。gitについてのある程度の事前知識があると助かるかもしれませんが、必須ではありません（事実、Fedoraパッケージングは、gitの導入は比較的簡単だと思われます）

あなたは、以下のようなことをずっと探していた、もしくは、興味があるかもしれません:

• パッケージの作り方を学ぶ
• パッケージの保守管理者になる
• パッケージ更新を投稿する
• 既存の保守管理者として レポジトリに新しいパッケージを追加する
• 既存パッケージに対して 新しいリリースブランチを登録する
• Fedoraパッケージガイドライン

fedpkg のインストールと初期設定の実施

dnf install fedpkg を実行して、fedpkg のインストールを開始してください。これは、パッケージ管理システムへの主要なインターフェースとなります。

あなたは、Fedoraアカウントシステム に、SSH鍵を設定もしなければいけません。あなた自身のパッケージを含む、いずれのパッケージに対する変更できるようにするためです。fedpkgは、あなたの鍵リング（訳注：ローカルPCに保存されるあなたのSSHログインセッションに関するデータベース）に、利用可能な正しいSSH鍵があることを期待しています。

最初に kinit で Kerberoseユーザ識別情報を取得しなければなりません。new-sources と upload でパッケージをアップしたり、例えば build でKojiの中でパッケージをビルドする前に、やります。次のように実行します。:

 kinit [FAS name]@FEDORAPROJECT.ORG

(FEDORAPROJECT.ORG は、全て大文字です)

~/.fedora.upn に、Fedoraアカウントシステムのユーザ名をセットしてください。echo "FAS_USERNAME" > ~/.fedora.upn と実行することもできます。

よく使われる fedpkg コマンド

このセクションでは、普段の一連の仕事の中で使う、典型的な fedpkg コマンドを短い説明とともに、表示しています。この一連の仕事の中では、パッケージの Rawhideブランチ上で 実行しています。

• パッケージをチェックアウトする:

fedpkg co <source_package_name>
cd <source_package_name>

詳細

サーバからパッケージソースのコピーを取得します。作業用コピーとして知られています。

• Fedoraサーバからチェックアウトしたコピーを更新する:

fedpkg pull

• パッケージソースを取得する:

fedpkg sources

詳細

"ルックアサイドキャッシュ"（詳細は下記参照）に保存されたパッケージソースを取得します。必要ならば、fedpkg prep そして fedpkg srpm で取得されますが、すぐにコピー（訳注：fedpkg sourcesを使って、だと思います）しても良いです。

• パッケージに変更をする

詳細

これはRPMパッケージガイドではありませんので、ここであなたがしていることをわかっていることを前提としています。新しいパッケージソースとパッチは、今、作業コピーのディレクトリにあります。

• チェックアウトしたディレクトリで、'prep'ステージ（ソースを展開してパッチを適用するなど）を実行する:

fedpkg prep

詳細

これはパッチが間違いなく適用されていることを確認するのに便利です。必要なときに、ソースツリーを調査するのにも便利です。

• ローカル環境で現在の状態をビルドする:

fedpkg local

詳細

これは一番簡単な部類のテストビルドです。しかし、MockかKojiでお試しビルド（下記参照）でテストする方が大抵はより間違いなく、より良いテストです。

• モック環境で現在の状態をビルドする:

fedpkg mockbuild

詳細

これはMock ビルドを開始します。Mockが正しく構成されている前提です。 パッケージのビルドテストのためにMockを使う を見ると、役に立つかもしれません。

• 現在の状態から .src.rpmファイルを作る:

fedpkg srpm

詳細

生成された .src.rpm から Koji の'お試しビルド' (レポジトリに行かずにテストビルドを実行) します。koji build --scratch コマンドで実行します。 (man kojiをみてください).

• Kojiでお試しビルドする: Koji scratch builds をみてください。
• あなたが変更した箇所を確認する:

fedpkg diff

詳細

これは間違って何かをさわってないことや、リリースし忘れたり、変更履歴に入れ忘れたりしてないことを確認するのに便利です。

• パッケージに対していくつかのチェックを走らせる:

fedpkg lint

詳細

いくつかのrpmlintのエラーをホワイトリストに登録し、エラーメッセージを表示させたくないなら、<source_package_name>.rpmlintrc という名前で、rpmlintの設定ファイルを作れます。そして、それは適用されます。

• 小さなパッチもしくはコミットする新しいソースファイルをステージにアップする:

git add (somefile)

詳細

git は、デフォルトでは、作業ディレクトリにある全部のファイルを、gitレポジトリの一部であるとみなしません。(これは、ソースツリーのような、関係ある他のファイルを保存するのに便利です)。このコマンドを実行すると、gitは、ローカル上で、これらのファイルをgitレポジトリの一部としてみなし始めます。コミットして、プッシュすると、この変更が、サーバに伝達されます。

• 新しいソースファイルをルックアサイドキャッシュ（訳注：アップストリームのためのストレージシステム）にアップロードする:

fedpkg new-sources

Alert
これは、現在のソースファイルの一覧を置き換えますが、一覧に追加はしません。詳細は ルックアサイドキャッシュシステムについてを参照。

fedpkg upload

詳細

オリジナルの開発元のソースコード(リリース用に作成されたtarファイルのような) とその他のより大きなソースファイルは、 ルックアサイドキャッシュ システムに保存されていて、gitに直接コミットはされていません。これは、より効率的な保存とファイル転送を提供します。レポジトリにある ソース と .gitignore ファイルは ルックアサイドキャッシュと同期しつづけます。fedpkg new-sources を使うか fedpkg upload が使われるときはいつでも、それらのファイルへの変更を忘れずにコミットしてください。

new-sources は、ゼロから始めます。つまり、そのときに ルックアサイドキャッシュ にある全部のファイルを置き換えます。通常このコマンドは、一個のtarファイルにまとめられているソースファイルを持つ多くのパッケージに対して、このコマンドが使われます。新しい開発元のバージョンに対して、アップデートするごとに行われます。upload は、与えられたファイルをすでにキャッシュにあるファイルに追加するだけです。周辺に置かれている古くなったソースファイルをそのままにしないようにしてください。

• 別のリリースブランチに移動する:

fedpkg switch-branch <f40, el6, master>

詳細

Fedoraリリースは、パッケージリポジトリにリリースごとのブランチを持っているので、異なるビルドを各リリースに送れます。ブランチを使った作業の詳細は下記参照してください。

• パッケージの変更履歴からgitのchangelogを生成する:

fedpkg clog

詳細

このコマンドはあなたのパッケージのchangelogエントリをclogというファイルに抽出します。もしあなたが望むならば、それをgit changelogとして使うこともできます。メンテナの中には両者を区別する人もいれば、そうしない人もいます。

• 変更をコミットする:

fedpkg commit (-F clog) (-p) (-c)

gitとの違い
デフォルトの挙動は、 git commit -a と似ています。- 変更されたファイルをステージに上げて、一度に全てをコミットします。しかし、まだgitが追跡していないファイルを追加はしません。

詳細

これは、レポジトリへのあなたの変更をまとめ、一つの'commit'とします。これには、独自の識別子と変更履歴を伴います。あなた以外のパッケージ保守管理者とあなた自身もまた、’commit' を通じて、最も細かいレベルの詳細情報として、レポジトリへの変更履歴を見られます。一つの目的ごとに、比較的小さくコミットすることをおすすめします。複数の空白の修正といくつかのスクリプトレットの修正を一つのコミットにまとめて、一つのバージョンとせずに、それぞれを別のコミットとして作ることをおすすめします。

-F clog パラメータは、clog ファイルを使います。これは、前のステップで変更履歴として使われているものです。-p は、コミットと同時に、プッシュします（詳細は下記参照）。-c は、 clog と commit -F clog のステップを一つにつなぎ合わせたものです。お好みで使えます。

• 変更をプッシュする:

fedpkg push

詳細

これは、ローカルの作業用コピーにある新しい’コミット'全てを上流のサーバに送信します。もしあなたがまだシステムについて勉強中であれば、今はfedpkg co を実行して、どこか他のレポジトリのもう一つのコピーに対して、あなたの作業用コピーに対してあなたが取得したものを比較してから、そこに対してテストビルドを走らせのが良いでしょう。

• プッシュした変更点を公式にビルドする:

fedpkg build

• ストリームブランチから公式ビルドを投稿する:

fedpkg build

詳細

複数のビルドを投稿するためのコマンドラインでは、ストリームブランチとの違いはありません。しかし、レポジトリにpackage.cfg という設定ファイルを作り、ビルドのための設定が必要となります。例えば、foo パッケージの 8 というストリームブランチには、次のような設定ファイルを作ります。

[koji]
targets = f28 epel7

この例では、あなたが build コマンドを実行した時に、fedpkg は f28 と epel7 のブランチで、リリースのためにビルドを投稿することができます。

実際には、便宜上 fedora と epel という短い名前を指定できます。fedpkgは、現在アクティブなFedoraとEPELのリリースを自動的に取得します。したがって、もしサブセットのリリースを選びたくない場合、もしくは、具体的なリリース名を知らずに、アクティブなリリースに対してパッケージをビルドしたいのなら、短い名前は便利です。rawhide 向けのビルドを指定する時は、 master という名前を使ってください。

• Docker コンテナ層のイメージビルドを使用している場合:

プロダクションに入れる
あなたが実際の利用者を本当の混乱を引き起こす可能性があります。ですから、注意して使いましょう。もし例にならって、Rawhideで動かす時は、あなたのビルドは、Rawhide向けに動くでしょう。Rawhideのユーザは、コマンドを打ってから、数時間後にビルドが有効になります。

プッシュした状態を使う
上で挙げたのほとんどのコマンドと違い、あなたがgitへプッシュした状態で動きます。ローカルの状態ではありません。もし問題があれば、すべてのパッチが正しくプッシュされて、コミットされていること、そして、ソースコードを正しく処理できていることを確認してください。

詳細

これは、あなたのパッケージをKojiで本当にビルド（お試しではなく）します。あなたがビルドしたリリースに依存するので、リリースは、直接stable 状態 になるかもしれませんし、アップデートプロセスを通じて、起動しなければならないかもしれません。詳細は、パッケージのアップデートガイドを見てください。コマンドは、あなたがKojiでのビルドの進行状況を確認できるURLを出力します。

• 最終ビルドのパッケージ更新を投稿する:

fedpkg update

詳細

繰り返しますが、ビルドのパッケージを更新するには、 パッケージ更新ガイド を見てください。このステップは、実際には、Rawhideには適用できませんが、完全を期すためにここに示しています。

典型的な fedpkg セッション

一つの典型的なセッションは次のような感じかもしれません:

fedpkg clone foo
cd foo
fedpkg sources
fedpkg new-sources foo-0.0.2.tar.bz2
gedit foo.spec       # specファイルの必要な部分を変更
                     # rpmdev-bumpspec は 簡単なバージョン更新には便利
fedpkg mockbuild     # あなたが行なった変更が正しいことを確認
fedpkg diff
fedpkg lint
fedpkg commit -p -c  # コミットしてプッシュを一回で実行

ブランチで作業する

各Fedoraのリリースは、gitレポジトリの中のブランチで表現されています。ブランチは次のように切り替えられます:

fedpkg switch-branch f40
fedpkg switch-branch f39
fedpkg switch-branch master

"master"ブランチは、Rawhide用です。各ブランチは完全に分離して維持管理できます。もし希望するなら、じっくりブランチ間の変更をコピーしてください（Updates Policy の要求の範囲内である限りは）。しかし、gitは、ブランチを取り扱うための便利ないくつかのツールを提供しています。例えば：

fedpkg clone bzrtools
# masterブランチで変更する
fedpkg new-sources bzrtools-2.2.tar.gz
gedit bzrtools.spec
fedpkg commit
fedpkg switch-branch f40
git merge master
# レポジトリにpush
fedpkg push

これは"master"(Rawhide)ブランチからf40ブランチへの変更点をマージします。gitマニアたちは、これはやや変わった業務フローだと気づくかもしれません。しかし、パッケージの保守管理という文脈においては、適切です。おぼえておいてほしいのは、Bodhiが有効にされた、安定版もしくはBranched リリースをプッシュしたりビルドした後では、他のFedoraユーザがあなたのビルドを見るよりも前に、アップデートを投稿する必要があります。

ブランチが以前に分岐しない場合に限り、マージは正常に機能することに注意してください。つまり、こうすれば、マージは衝突("merge conflict")するかもしれません。

fedpkg clone bzrtools
# masterブランチで変更する
fedpkg commit
fedpkg switch-branch f40
# f40 ブランチで変更する
fedpkg commit
fedpkg switch-branch master
# masterブランチで変更する
fedpkg commit
fedpkg switch-branch f40
git merge master

gitは、"協働的"なシステムであり、Fedoraパッケージ管理においては、そのように使われていることを忘れないでください。多くの場合、あなたは、あるパッケージに他の人が加えた変更を考慮しなければならず、あなたの変更が他の人にも影響があるということを考慮しなければなりません。

衝突したマージを解決する

これは大きな話題です。そして、このガイドの範囲を幾分か超えます。しかし、基本的な視点を提示します。他に良い参考文献がgit book やgithubにあります。

あなたが git mergeするとき、衝突が発生したとき、衝突しているファイルを編集できます。ファイルの中の衝突マークを取り除き、手で変更箇所をマージしましょう。git diff もしくは fedpkg diffを使って、競合前の状態の変更箇所を精査し、その解決であなたが幸せであることを確認しましょう。

git mergetoolを使って競合を解決する

Gitは、グラフィカルなプログラムを提供しており、それは、競合を解決する手助けをしてくれます。これは、どのような変更が起きたかを可視化し、一つのセットとして変更を扱う点が便利です。

git config --global merge.tool meld
fedpkg switch-branch f40
git merge master
# 競合が発生した
git mergetool            # マージ、作業ツリー、最後のコミットの三つを 
                         # 一つにして表示する。
# GUIの中ですべての競合を解決する。
git add CONFLICTEDFILES
git commit

特別なdistタグをリクエストする

あるパッケージに対する変更が、大量の依存関係に影響する場合（例えば、perl, pyton, rubyもしくはghcパッケージのすべて）、それらをリビルドする必要があるので、特別なレポジトリの中で、最初にビルドしてしまうのが良いかもしれません。そうすれば、Rawhideであまり破壊的なことは起きません。

あなたがこのようなケースに陥るアップデートを抱えていると考えるならば、あなたは、リリースエンジニアリングチケットを発行し、特別なdistタグを要求できます。おそらくリリースエンジニアリング出身の誰かが、本当に適切なケースであるか、そして、あなたが必要とするものをあなたが獲得することを確認するために、あなたの必要性について議論したがるでしょう（あなたに確信がなければ、質問するのはOKです）

小技とトリック

匿名でfedpkgを使う

次のようにfedpkgを使えます:

fedpkg clone --anonymous <somepackage>

ID確認なしでパッケージをチェックアウトします。もちろんレポジトリに対して変更をプッシュはできませんが、パッケージャーでない人がパッケージを単に精査したり、自分の用途に合わせて変更を加えたい、そしておそらくFedora開発者に変更を提出したいときに便利です。

ローカルなブランチ名

もしgitコマンドを使って、ブランチし、直接チェックアウトするなら、あなたが希望するどのようなローカルブランチ名でも定義できます。もし、fedpkg switch-branchを使うならば、上の例で使われている名前がデフォルトで作成されます。

シェルプロンプトに現在のブランチと状態を表示する

よく助かるのが、一目であなたが作業しているブランチがわかることです。あなたは、この情報をバッシュのプロンプトに追加できます。ここに書かれている情報をみてください。

更新のために.src.rpmをインポートする

fedpkg import コマンドは、最初に.src.rpmファイルからgitパッケージレポジトリを作成するために使われます。特にあなたが愛着をもっている古いパッケージングプロセスパッケージレビュー手順では、作業コピーをアップデートするためにも使われます。 ただ単に fedpkg import file.src.rpm を実行して、新しいtarで固めらたファイルをルックあサイドキャッシュにアップし、gitに見つかった最新バージョンの作業コピーを更新し、すべての変更をコミットします。fedpkg import --help すると、他にも受け取るパラメータのドキュメントが表示されます。

注意!
このやり方は、あなたの変更が安全であるか確認するのが難しくなります。他の人が行なった変更を上書きしないでください。この理由のために、このやり方は非推奨となっています。

アップグレードパスを壊さずに古いブランチでの変更する

想定されるシナリオ: あなたは、40ブランチで、パッケージビルドに成功しましたが、lastでは、ビルドできない問題が起きています。

解決策: そのブランチで変更し、リリースタグの一番右に、数字を追加します。他のブランチでは、リリースを変更するはありません。これにより、ユーザがFedoraの新しいリリースにアップグレードした場合でも、アップグレードはスムーズに機能します。

Name:    foo
Version: 1.0
Release: 1%{?dist}

Name:    foo
Version: 1.0
Release: 1%{?dist}.1

タグとビルドはいつも通りです。このアプローチは、最初に in this mailing list thread で議論されました。

Rawhide または Branchedでペンディングになっているパッケージビルドを削除する

時々あなたがRawhideやアルファ版以前のブランチに投稿したパッケージを削除したいと思うかもしれません。(both cases where the build would usually go out to the main repository without further gating). これは、パッケージ開発元が次のリリースで修正される予定だけど、あなたのパッケージには、バグや問題がある状況で起こり得ます。もしくは、あなたがビルドで重大な間違いを犯したために簡単に修正できないと気づく場合もあります。

注意して使うこと！
これは、compose(Fedoraのスナップショット)にパッケージが含まれる前の状態で、ビルドした日と同じ日でだけ実施されるべきです。 もし、パッケージがcomposeに含まれてしまっていたならば、タグを外してはいけません。Release Engineering Dashboard を確認して、最後のcomposeが始まった時刻を確認してください。

Koji: koji untag-pkg f41 foo-1.1.3-1.fc41をつかって、パッケージを削除できます。

foo-1.1.3-1.fc41 となっている部分は、あなたのパッケージビルドの名前に置き換えてください。詳細は、koji help もしくは Kojiを使う を見てください。

SSHの指紋

~/.ssh/config に、"VerifyHostKeyDNS yes" を含めることをお勧めします。これは、鍵が正しいことをDNSを使って結論づけます。

https://admin.fedoraproject.org にある鍵の一覧と照合することもできます。そこにある文字列は〜/ .ssh / known_hostsファイルに入っています。ですから、あなたは、プロンプトが出たときに、〜/ .ssh / known_hostsファイルに入っている src.fedoraproject.org の正しい文字列であることを確認して、文字列を受け入れることができます。

レポジトリに接続中に発生する問題

fedpkg ツールは、ssh:// プロトコルを使って、レポジトリをクローンします。ですので、普通これは、問題になるべきではありません（あなたが自分のSSH鍵をつかっている限りは）。もし、"git" ユーティリティそれ自体を使ってクローンしているならば、.git/config ファイルを確認して、リモートレポジトリが ssh:// 経由でアクセスされていることを確認してください。git:// 経由ではありません。

ここでビルドして、なんでそこでビルドしない？

あなたのパッケージはローカルでビルドされていますか？Mockを使っていても、スクラッチビルドとしてもです。- しかし、fedpkg build を実行したときではありませんか? イラつく前に、思い出してください。fedpkg build は、パッケージがアップストリームのレポジトリの中にあるように、動いています。あなたのローカルのワーキングコピーではありません。すべての変更とソースファイルがコミットされ、プッシュされ、ルックアサイドキャッシュを正しく処理していることを確認してください。報告されている他の問題としては、build / make check parallelizationや、テストスイートが原因で失敗することが挙げられます（そしてビジーなビルドシステムは時間通りに操作を実行できないかもしれません）。

References

• https://src.fedoraproject.org/
• Infrastructure/Kerberos
• Package SCM admin requests
• Package_Renaming_Process
• PackageMaintainers/PackagingTricks
• Package_update_HOWTO
• PackageMaintainers/BuildSystemClientSetup#Install_the_Client_Tools_.28Koji.29
• PackageMaintainers/MockTricks#How_do_I_use_Mock.3F
• Using_the_Koji_build_system
• Package_Review_Process
• Fedora_Release_Life_Cycle
• PackageMaintainers/Join
• Infrastructure/VersionControl/dist-git