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鍵があることを期待しています。

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

 kinit [FAS name]@FEDORAPROJECT.ORG

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

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

よく知られている fedpkg コマンド

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

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

fedpkg co <source_package_name>
cd <source_package_name>

詳細

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

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

fedpkg pull

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

fedpkg sources

詳細

"lookaside cache"（詳しくは下をみてください）に保存されたソースを引っ張ってきます。必要ならば、fedpkg prep そして fedpkg srpm でこれを実施するのですが、あなたはすぐにコピーが欲しいのかもしれません。

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

詳細

これは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

詳細

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

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

fedpkg lint

詳細

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

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

git add (somefile)

詳細

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

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

fedpkg new-sources

Alert
これは、現在のソースファイルの一覧を置き換えますが、一覧に追加はしません。詳しくは lookaside cache システムについての詳細を見てください。

fedpkg upload

詳細

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

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

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

fedpkg switch-branch <f41, el6, master>

詳細

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

• パッケージのchangelogから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には適用できませんが、完全を期すためにここに示しています。

Typical fedpkg session

A typical session may look like this:

fedpkg clone foo
cd foo
fedpkg sources
fedpkg new-sources foo-0.0.2.tar.bz2
gedit foo.spec       # change the required things in the specfile.
                     # rpmdev-bumpspec is useful for simple version updates
fedpkg mockbuild     # check that the changes you made are correct
fedpkg diff
fedpkg lint
fedpkg commit -p -c  # commit and push in one go

Working with branches

Each Fedora release is represented by a branch in the git repository. You can switch between them like this:

fedpkg switch-branch f41
fedpkg switch-branch f40
fedpkg switch-branch master

The master branch is for Rawhide. You can maintain each branch entirely separately, if you like, laboriously copying changes between them (so long as you always stay within the Updates Policy requirements). However, git provides us with several handy tools for working with branches. Here's an example:

fedpkg clone bzrtools
# Make some changes in the master branch
fedpkg new-sources bzrtools-2.2.tar.gz
gedit bzrtools.spec
fedpkg commit
fedpkg switch-branch f41
git merge master
# for push into repo
fedpkg push

This will 'merge' the changes from the master (Rawhide) branch to the f41 branch. git aficionados may note this is a somewhat unusual workflow, but it is appropriate to the context of package management. Remember, after pushing to and building for a stable release or a Branched release after Bodhi has been enabled, you will have to submit an update before any other Fedora users will see your build.

Note that merges will only be sure to work cleanly so long as the branches have not previously diverged. That is, if you do this:

fedpkg clone bzrtools
# Make some changes in the master branch
fedpkg commit
fedpkg switch-branch f41
# Make some changes in the f41 branch
fedpkg commit
fedpkg switch-branch master
# Make some more changes in the master branch
fedpkg commit
fedpkg switch-branch f41
git merge master

you may encounter a merge conflict.

Remember that git is a collaborative system, and used as such in Fedora package management. It is often the case that you must consider changes made by others in working on a package, and consider how your changes will affect others.

Resolving merge conflicts

This is a large topic and somewhat beyond the scope of this guide, but we can give basic pointers. There are other good references in the git book and at github.

When you git merge and a conflict occurs you can edit the files that have conflicts. Remove the conflict markers in the files and merge the changes manually. Use git diff or fedpkg diff to inspect the changes against the pre-conflict state and verify you are happy with the resolution. Then you can commit the files with fedpkg commit or git commit -a. git will know if you have resolved the conflict by checking that all the conflict markers have been removed.

Using git mergetool to resolve conflicts

Git provides a graphical diff program to help resolve conflicts. This can be handy for visualizing what changes have occurred and dealing with them as a set.

git config --global merge.tool meld
fedpkg switch-branch f41
git merge master
# Conflicts occurred
git mergetool            # Opens up a meld showing a three way diff of 
                         # the merge, working tree, and the last commit
# Resolved all the conflicts in the GUI
git add CONFLICTEDFILES
git commit

Requesting special dist tags

When a change to a package affects a large number of dependencies (e.g. all perl, python, ruby or ghc packages), requiring them to be rebuilt, it may be better to initially do the builds in a special repository, so that there is less disruption in Rawhide.

If you think you have an update that falls under this case you can request a special dist tag by filing a release engineering ticket. Someone from release engineering will likely want to discuss your needs to make sure this is really an appropriate case (it's OK ask if you aren't sure) and that you get what you need.

Tips and tricks

Using fedpkg anonymously

You can use fedpkg like this:

fedpkg clone --anonymous <somepackage>

to check out a package without requiring identification. Obviously, you will not be able to push any changes to this repository, but it is useful for non-packagers who simply want to examine a package, make changes for their own use, and perhaps submit changes to a Fedora developer.

Local branch names

If you use git commands to branch and checkout directly, you can define whatever local branch names you want. If you use fedpkg switch-branch, it will default to creating the names used in the examples above.

Current branch and state in shell prompt

It is often helpful to know what branch you are working on at a glance. You can add this information to your bash prompt with the information here.

Importing a .src.rpm to update

The fedpkg import command usually used to initially populate a git package repository from a .src.rpm that has been through the Package Review Process can also be used to update a normal working copy, if you have an old-school packaging process to which you are particularly attached. Just run fedpkg import file.src.rpm and it will upload new tarballs into lookaside cache, update a working copy of the last version found in git, and commit all changes. fedpkg import --help documents some other parameters it can accept.

Caution!
This approach makes it harder to verify that your changes are safe and do not overwrite changes made to the package by others. For this reason, its use is not recommended.

Making changes on an older branch without breaking the upgrade path

Here is the scenario: you've built your package successfully on the 41 branch, but there is a problem keeping your package from building on last.

Solution: make your changes in the branch and then add a digit to the very right of the release tag. There is no need to change the release in the other branches. This allows upgrades to work smoothly if the user upgrades to a newer release of Fedora.

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

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

Then tag and build as usual. This approach was initially discussed in this mailing list thread.

Removing a package build pending for Rawhide or Branched

From time to time you may want to remove a package build you submitted to Rawhide or to Branched prior to the Alpha freeze (both cases where the build would usually go out to the main repository without further gating). This could happen in a situation where a bug or issue is found in your package that will be resolved upstream in the next release, or you realize you made a significant mistake in the build that cannot easily be corrected.

Use this carefully!
This should only be done on the same day of the build, before it is included in a compose. If your build was already included in a compose you must not untag it! Check the Release Engineering Dashboard to get the starting time of the last compose.

You can remove the package by using Koji: koji untag-pkg f42 foo-1.1.3-1.fc42

where foo-1.1.3-1.fc42 is replaced with the name of your package build. See koji help or using Koji for more information.

ssh fingerprint

The recommended option is to include "VerifyHostKeyDNS yes" in your ~/.ssh/config file. This will result in using DNS to check that the key is correct.

But you can also manually check against the list of keys at https://admin.fedoraproject.org . The strings there are what ends up in your ~/.ssh/known_hosts file. So you can accept the fingerprint when prompted and then check that the correct string for src.fedoraproject.org ended up in your ~/.ssh/known_hosts file.

Problems connecting to the repository

The fedpkg tool clones repositories using the ssh:// protocol, so this should not be a problem normally (as long as you have your ssh key). If you cloned using the git utility itself, check the .git/config file to ensure the remote repository is being accessed via an ssh:// protocol, and not git://.

It builds here, why doesn't it build there?

Is your package building locally - even with Mock, even as a scratch build! - but not when you run fedpkg build? Before you get too frustrated, remember fedpkg build runs on the package as it exists in the upstream repository, not your local working copy. Make sure you have committed and pushed all changes and source files, and handled the lookaside cache correctly. Other issues that have been reported, are issues because of build/make check parallelization and failures because of test suites that depend on operations finish on precise timing (and a busy build system may not be able to perform operations on time).

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