[edit]このページでは、gitベースのFedoraのパッケージ保守管理システムの、日常的に行う基本操作を説明しています。主な対象読者は、新規、及び、既存のFedoraのパッケージ保守管理者です。簡単に匿名かつ読み取り専用でのシステムの利用も含んでいます。このガイドは、RPMパッケージングガイドではありません。インストールを開始してください。これは、パッケージ管理システムへの主要なインターフェースとなります。SSH鍵を設定もしなければいけません。あなた自身のパッケージを含む、いずれのパッケージに対する変更できるようにするためです。fedpkgは、あなたの鍵リング(訳注:ローカルPCに保存されるあなたのSSHログインセッションに関するデータベース)に、利用可能な正しいSSH鍵があることを期待しています。Kerberoseユーザ識別情報を取得しなければなりません。次のように実行します。Fedoraアカウントシステムのユーザ名をセットしてください。コマンドを短い説明とともに、表示しています。それぞれのコマンドの長い説明は、'Show'リンクをクリックすると見られます。<source_package_name>詳細サーバからパッケージソースのコピーを取得します。作業用コピーとして知られています。cache"(詳しくは下をみてください)に保存されたソースを引っ張ってきます。これを実施するのですが、あなたはすぐにコピーが欲しいのかもしれません。パッケージに変更をする詳細これはRPMパッケージガイドではありませんので、ここであなたがしていることをわかっていることを前提としています。新しいソースとパッチは、今のところ作業コピーのディレクトリにあります。prep詳細これはパッチが間違いなく当たっていることを確認するのに便利です。あなたがそうする必要があるならば、ソースツリーを調査するのにも便利です。local詳細これは一番簡単な部類のテストビルドです。MockかKojiでお試しビルド(下を見て)でテストする方が大抵はより間違いなく、より良いです。Mockが正しく構成されている前提です。見ると、役に立つかもしれません。コマンドで実行します。diff詳細これは間違って何かをさわってないことや、リリースし忘れたり、Changelogに入れ忘れたりしてないことを確認するのに便利です。いう名前で、rpmlintの設定ファイルを作ることができ、それが適用されます。デフォルトでは、作業ディレクトリにある全部のファイルを、gitレポジトリの一部であるとみなしません。このコマンドを実行すると、gitは、ローカル上で、これらのファイルをgitレポジトリの一部としてみなし始めます。コミットして、プッシュすると、この変更が、サーバに伝達されます。new-sourcesAlertこれは、現在のソースファイルの一覧を置き換えますが、一覧に追加はしません。システムについての詳細を見てください。システムに保存されていて、gitに直接コミットはされていません。これは、より効率的な保存とファイル転送を提供します。cacheと同期しつづけます。使われるときはいつでも、それらのファイルへの変更を忘れずにコミットしてください。cacheにある全部のファイルを置き換えます。通常このコマンドは、一個のtarファイルにまとめられているソースファイルを持つ多くのパッケージに対して、このコマンドが使われます。新しい開発元のバージョンに対して、アップデートするごとに行われます。与えられたファイルをすでにキャッシュにあるファイルに追加するだけです。周辺に置かれている古くなったソースファイルをそのままにしないようにしてください。master>詳細Fedoraリリースは、パッケージリポジトリにリリースごとのブランチを持っているので、異なるビルドを各リリースに送れます。ブランチを使った作業の詳細については下をみてください。clog詳細このコマンドはあなたのパッケージのchangelogエントリをclogというファイルに抽出します。changelogとして使うこともできます。メンテナの中には両者を区別する人もいれば、そうしない人もいます。変更されたファイルをステージに上げて、一度に全てをコミットします。gitが追跡していないファイルを追加はしません。詳細これは、レポジトリへのあなたの変更をまとめ、一つの'commit'とします。これには、独自の識別子と変更履歴を伴います。通じて、最も細かいレベルの詳細情報として、レポジトリへの変更履歴を見られます。一つの目的ごとに、比較的小さくコミットすることをおすすめします。複数の空白の修正といくつかのスクリプトレットの修正を一つのコミットにまとめて、一つのバージョンとせずに、それぞれを別のコミットとして作ることをおすすめします。これは、前のステップで変更履歴として使われているものです。コミットと同時に、プッシュします(下をみてください)。ステップを一つにつなぎ合わせたものです。push詳細これは、ローカルの作業用コピーにある新しい’コミット'全てを上流のサーバに送信します。実行して、どこか他のレポジトリのもう一つのコピーに対して、あなたの作業用コピーに対してあなたが取得したものを比較してから、そこに対してテストビルドを走らせのが良いでしょう。複数のビルドを投稿するためのコマンドラインでは、ストリームブランチとの違いはありません。いう設定ファイルを作り、ビルドのための設定が必要となります。いうストリームブランチには、次のような設定ファイルを作ります。ブランチで、リリースのためにビルドを投稿することができます。いう短い名前を指定できます。fedpkgは、現在アクティブなFedoraとEPELのリリースを自動的に取得します。したがって、もしサブセットのリリースを選びたくない場合、もしくは、具体的なリリース名を知らずに、アクティブなリリースに対してパッケージをビルドしたいのなら、短い名前は便利です。いう名前を使ってください。コンテナ層のイメージビルドを使用している場合:プロダクションに入れるあなたが実際の利用者を本当の混乱を引き起こす可能性があります。注意して使いましょう。例にならって、Rawhideで動かす時は、あなたのビルドは、Rawhide向けに動くでしょう。Rawhideのユーザは、コマンドを打ってから、数時間後にビルドが有効になります。プッシュした状態を使う上で挙げたのほとんどのコマンドと違い、あなたがgitへプッシュした状態で動きます。ローカルの状態ではありません。問題があれば、すべてのパッチが正しくプッシュされて、コミットされていること、そして、ソースコードを正しく処理できていることを確認してください。詳細これは、あなたのパッケージをKojiで本当にビルド(お試しではなく)します。なるかもしれませんし、アップデートプロセスを通じて、起動しなければならないかもしれません。詳細は、パッケージのアップデートガイドを見てください。コマンドは、あなたがKojiでのビルドの進行状況を確認できるURLを出力します。このステップは、実際には、Rawhideには適用できませんが、完全を期すためにここに示しています。Guidelines。