m (第三セクション更新) |
m (第五セクション) |
||
Line 179: | Line 179: | ||
}} | }} | ||
== | == 特別なdistタグをリクエストする == | ||
あるパッケージに対する変更が、大量の依存関係に影響する場合(例えば、perl, pyton, rubyもしくはghcパッケージのすべて)、それらをリビルドする必要があるので、特別なレポジトリの中で、最初にビルドしてしまうのが良いかもしれません。そうすれば、Rawhideであまり破壊的なことは起きません。 | |||
あなたがこのようなケースに陥るアップデートを抱えていると考えるならば、あなたは、[https://fedorahosted.org/rel-eng/newticket リリースエンジニアリングチケット]を発行し、特別なdistタグを要求できます。おそらく[[ReleaseEngineering|リリースエンジニアリング]]出身の誰かが、本当に適切なケースであるか、そして、あなたが必要とするものをあなたが獲得することを確認するために、あなたの必要性について議論したがるでしょう(あなたに確信がなければ、質問するのはOKです) | |||
== Tips and tricks == | == Tips and tricks == |
Revision as of 05:15, 29 March 2019
このページでは、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
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)
これは、レポジトリへのあなたの変更をまとめ、一つの'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 コンテナ層のイメージビルドを使用している場合:
- 最終ビルドのパッケージ更新を投稿する:
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です)
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.
Making changes on an older branch without breaking the upgrade path
Here is the scenario: you've built your package successfully on the 40 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.
You can remove the package by using Koji: koji untag-pkg f41 foo-1.1.3-1.fc41
where foo-1.1.3-1.fc41
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