EPEL/GuidelinesAndPolicies/ja

EPEL 向けのパッケージングガイドラインとポリシー

EPEL におけるパッケージングは Fedora のパッケージングとメンテナンスガイドラインに従います。 FESCo とパッケージング委員会によってメンテナンスされたパッケージングガイドライン、パッケージ名ガイドライン、パッケージレビューガイドライン、そしてパッケージングポリシーになりますが、それらに制限されたものではありません。次のような EPEL に特化した例外事項もあります。

"ガイドライン" と "ポリシー" のセクションはわざとそのような名前を使用していることに注意してください。ガイドラインは通常守るべき内容と考えてください。しかし、そうしない理由が何かあるなら守る必要はありません。その理由が適切かどうか疑問に思ったら EPEL SIG メンバーへ尋ねてください。"ポリシー"という言葉には強い意味があります。そのセクションに記載された内容は必ず守らなければならないルールと考えてください。

パッケージメンテナンスと更新ポリシー

EPEL は我々のリポジトリのユーザに対して共通の "見た目" を提供したいです。そのため EPEL SIG は EPEL におけるパッケージメンテナンスと更新のための規定を定めたポリシーを作成しました。そのポリシーは現在の Fedora の規定よりも少しだけ厳しい内容になります。

ダイジェスト

その目的はエンタープライズ Linux ディストリビューションを拡張するパッケージを EPEL に持つことです。つまり、そのディストリビューションから提供されている元のパッケージを置き換えるか、提供されていないパッケージに対してビルドしたものを提供することです。リポジトリにあるパッケージは、可能なら、エンタープライズ Linux ディストリビューション向けにビルドされたエンタープライズなパッケージと似たような方法でメンテナンスされるべきです。言い換えると、何か理由があればその部分のみを変更し、通常は何も変更しないパッケージの安定版セットを多く持つことです。"やあ、新しいバージョンがあるからビルドしたよ、それを提供しようよ"といった考え方ではありません。

ポリシー

EPEL パッケージは機能拡張のみを目的にするもので、決してエンタープライズ Linux ディストリビューションのためにビルドされたパッケージの品質を悪くするものではありません。つまり EPEL パッケージは、ベースディストリビューションやその派生プロダクトを含めた対象ディストリビューションで提供されているパッケージを置き換えることは決してしません。例えば、カーネルモジュールの追加は、ちょっとしたことでベースカーネルの動作に影響することがあるので認められません。

リポジトリにあるパッケージは、可能ならば、エンタープライズディストリビューション向けにビルドされたパッケージとよく似た方法でメンテナンスすべきです。言い換えれば、ほとんどの安定版パッケージは通常は決して変更せず、変更をするのに適切な理由がある場合のみ変更します。これは安定したエンタープライズ環境を提供するための基本的な考えです。

行わなければならない変更は異なるリリースツリーの中に入れます。重要なバグ(データ汚染、セキュリティの問題、本当に悩ましいバグ)を修正するアップデートのみ、短期間、テストブランチに置かれた後に安定版ブランチへ追加されます。パッケージに署名をして、EPEL パッケージを公開 repo へ追加する担当者は、"安定版ブランチのための重要なアップデートのみ" という目的が実行されていることを確認するために、安定版 repo のための更新パッケージリストに目を通します。

その他のアップデートは徐々にテストリポジトリへ追加されます。テストリポジトリは少なくとも2週間テストされた後に新たな安定版ブランチになります。しかし、これらのアップデートはできるだけ修正のみに制限されるべきです。もしできれば、事前に Fedora でテストすべきです。ABI を変更する、又は設定ファイルの変更が必要なアップデートパッケージはできるだけ避ける必要があります。もし ABI を変更する以外にパッケージをアップデートする方法がないなら、旧 ABI を提供する Compat パッケージをリポジトリで提供する必要があります。テスト repo にあるパッケージは依存関係の問題やメンテナが安定していると感じていない箇所があり、安定版リポジトリへの追加を控えています。メンテナは、2週間後又はアップデートパッケージに十分なカルマを体得した後、安定版リポジトリへ追加するためにリクエストする必要があることを覚えておいてください。テストリポジトリから安定版リポジトリへ自動的に追加するようなことはありません。

3ヶ月ごとの新しいアップデートがリリースされる場合、EPEL はそのアップデートが利用可能になる CentOS のバージョンがリリースされるまで待つでしょう。

ワークフローの例 / 情報

• メンテナは通常 'make build' を使用してパッケージをビルドします
• メンテナは bodhi('make update' 又は web インタフェース経由で) を使用してアップデートリクエストを実行します
• セキュリティやクリティカルなバグ修正でない限り、アップデートは少なくとも2週間テストリポジトリに置かれなければなりません。
• 2週間後、bodhi からメンテナへ2週間経過したことを知らせるメールが届くでしょう。
• この時点でメンテナがそのパッケージが安定している、又は十分なカルマを体得して安定版リポジトリへの追加リクエストをするなら、次回のアップデートの追加時に安定版リポジトリへ追加されます。
• テストリポジトリへの追加はほぼ毎日行われます。安定版リポジトリへの追加は隔週の火曜日に行われます。
• アップデートはメンテナが追加リクエストを行う、又は十分なカルマを体得していない限り、決してテストリポジトリから安定版リポジトリへ追加されません。(自動的にアップデートが安定版リポジトリへ追加されません)

このポリシーのガイドラインと背景

パッケージを更新して良いかどうかの例

上述したポリシーを実際に適用する方法の大まかな概要を把握するのに役立つことを願って複数の例を紹介します。

マイナーバージョンアップ

EPEL 5.0 でパッケージ foo がバージョン 1.0.1 として提供されたと仮定します。アップストリームの開発者は、現在 1.0.2 を提供しています。

• 通常通りビルドしますが、少なくとも2週間、できればもう少しテストリポジトリで待ちます。

マイナーバージョンアップよりは少しだけ大きな修正

EPEL 5.0 でパッケージ foo がバージョン 1.0.1 として提供されたと仮定します。アップストリームの開発者は、現在 1.2.0 を提供しています。ABI は 1.0.1 と互換性があり、既存の設定ファイルはそのまま動作します。

• 通常通りビルドしますが、安定版リポジトリへ追加するために十分なカルマを体得するまでテストリポジトリに置かれます。

マイナーバージョンアップより少しだけ大きな修正のさらなる別の修正

EPEL 5.0 でパッケージ foo がバージョン 1.0.1 として提供されたと仮定します。アップストリームの開発者は、現在 1.4.0 を提供しています。ABI は 1.0.1 と互換性がありますが、設定ファイルは手動で調整する必要があります。

• 安定版ブランチ向けのビルドは通常は認められません。それが修正しなければならない深刻なバグ修正を含んでいるなら、バックポートすることを積極的に検討すべきです。
• テストブランチ向けのビルドも同様に好まれませんが、深刻なバグ修正をする簡単な方法が他にないのであれば認められます。しかし、そのアップデートは設定ファイルを調整する必要があることをユーザへ適切にアナウンスする必要があります。アナウンスには epel-announce メーリングリストを使用してください。
• 可能な限り、テストリポジトリへ置かれます。

メジャーバージョンアップ

EPEL 5.0 でパッケージ foo がバージョン 1.0.1 として提供されたと仮定します。アップストリームの開発者は、現在 2.0.0 を提供しています。ABI が変更されるか、設定ファイルは手動で調整する必要があります。

• このアップデートは可能な限り、避けられるべきです。深刻なバグを修正する方法が本当に他にないなら、テストブランチ向けに新たなバージョンをビルドすることが認められる稀なケースです。そして、次回のアップデート時のリリースノートに、そのアップデート内容と設定ファイルの調整が必要なことを記載します。もし ABI が変更されたなら、旧ライブラリを使用する追加の compat パッケージが必要です。

セキュリティアップデート

セキュリティアップデートはそれ自体は bodhi と見なされるべきで、安定版リポジトリへ追加されるでしょう。このために、様々な修正内容の中からできるだけ少ない修正でアップデートパッケージを作成するようにすべきです。バックポートされた修正のみ、又はあなたが必須だと思うものを適用するか、その修正のみを提供する新バージョンを提供してください。セキュリティアップデートと他の修正を一緒に追加しないようにやってみてください。

パッケージに関する多くのドキュメントを追加する

もし多くのパッケージに関するドキュメントを追加するなら、分割されたドキュメント内へ追加するようにしてください。

EPEL 向けにパッケージを提供して良いかどうか自信がない

EPEL 開発者メーリングリストか、freenode.org の #epel チャンネルで尋ねてみて EPEL SIG メンバーから意見をもらうようにしてください。

Fedora Extras で行っていたように最新パッケージでリリースを行わないのはなぜですか？

どうして我々なのですか？Fedora Extras で行われていたことや活動したこと、うまく活動していることもあります。しかし、主には Fedora (Core) があまりにも早い前倒しのリリーススキーム/サイクルのために、多くのアップデートパッケージを持つことになってしまいます。我々がビルドしたエンタープライズ Linux はより長期間のライフサイクルで、もっと慎重なアップデートパッケージを提供します。つまり、EPEL 向けのパッケージもエンタープライズ Linux と同様にすべきです。大半のユーザは、彼らが何らかの理由があって安定したディストリビューションを選択したように、Fedora Extras のような方法よりも EPEL のような慎重なアップデートパッケージを提供する方法をおそらくは好みます。もし最新のパッケージを欲しいなら、Fedora を選択しているでしょう。

もちろん、求められたパッケージに加えて、かなり新しいパッケージのセットと安定したベースとなるパッケージを混在させて提供できる部分も多くあります。*たぶん* EPEL プロジェクトは長期間、それらの問題に対する解決方法(並行して慎重にリポジトリを更新しながら)を提供するでしょう。しかし、それを始めることはしません。既にこの方向性で何らかのパッケージを提供するサードパーティのリポジトリがあります。そのため、もうユーザはそういったリポジトリからパッケージを取得しているでしょう。

もっと突っ込むと、Fedora Extras が行ったような前倒しのリリーススキームは別の理由で多くの EPEL パッケージャにとっては難しいです。新しいパッケージはよくコアライブラリの特定のバージョンを要求します。これは EPEL において問題を引き起こします。それは OS のコアになるライブラリ群を置き換えるようなアップデートライブラリを提供することができないからです。

例として、このドキュメントは RHEL5 がリリースされたときに書かれました。RHEL5 向けにビルドされた多くのパッケージは、この時点で既に RHEL4 向けにはビルドできませんでした。例えば、RHEL4-gtk2 は2年前のもので、多くのカレントのアプリケーションでは古く、依存するパッケージは新しい gtk2 を必要とします。そのため、たとえかなり新しいパッケージを前倒しのスキームで提供しようとしても我々は失敗するでしょう。例えば、ライブラリの依存関係のためにビルドできなかったりします。結果的にリポジトリにはかなり新しいパッケージと大半のかなり古いパッケージが残ります。そういったパッケージを混在させることは "最新パッケージ" か "慎重なアップデートパッケージのみ" かのどちらか一方しか幸せにしないでしょう。そのため、我々は目的を "慎重なアップデートパッケージのみ" に絞り込んでいます。EPEL のサポートとアップデートサイクルは Fedora のライフサイクルよりもずっと長期に渡ることを覚えておいてください。

EPEL から Fedora パッケージを取得する

EPEL にある Fedora パッケージを取得する手続きをご覧ください。

ディストリビューションに特化したガイドライン

EL5 やそれよりも前のディストリビューションでは noarch サブパッケージをサポートしません。noarch パッケージの debuginfo ファイルをパッケージングできないことでビルドに失敗するなら、EL5 やそれよりも前のディストリビューション上で使用されない noarch パッケージに関して BuildArch: noarch がラップされます。

エンタープライズ Linux 4

• EPEL4 Python パッケージは、ビルドされた適切な python のバージョンに依存するように手動で行うべきです。多くの旧 FC-3 python パッケージはこのトリックをまだ使用すべきです。
• EPEL4 Python パッケージは spec ファイルの中で .pyc や .pyo ファイルを生成する必要があります。あなたのモジュールが distutils か setuptools を使用しているなら、%install に次のコマンドを記載してください。

  %{__python} setup.py install --skip-build --root $RPM_BUILD_ROOT
  %{__python} setup.py install -O1 --skip-build --root $RPM_BUILD_ROOT
  

エンタープライズ Linux 5

• EPEL5 の rpm や次のモノは自動的に pkgconfig ファイルのために依存関係を作成しません。pkgconfig(.pc) ファイルを含んでいるパッケージは (ディレクトリの所有者と使い勝手のために) Requires: pkgconfig を設定しなければなりません。
• EPEL5 では *.py にマッチする全てのファイルをバイトコンパイルする brp-python-bytecompile によって、自動的に python ファイルのバイトコンパイルが実行されます。これは %{_bindir} や %{_sbindir} にあるプログラムファイルにとっては好ましくありません。ユーザは、おそらくメインのプログラムしか実行せず、これらのファイルは決して実行しないからです。そして python はこれらのファイルを使用しないでしょう。このバグが解決されるまで、2つの回避策があります。
  1. %{_bindir} にあるスクリプトを .py という拡張子を持たないようにリネームしてください。例えば、/usr/bin/orient.py から /usr/bin/orient のようにします。
  2. ファイルの読み込みからスクリプトを除外する %exclude を使用してください。

     %files
     %{_bindir}/orient.py
     %exclude %{_bindir}/orient.pyc
     %exclude %{_bindir}/orient.pyo
     

BuildRoot タグ

EPEL5 の rpm や次のモノは自動的に BuildRoot タグ設定を提供しません。そのため、パッケージャによって spec ファイルの中で設定しなければなりません。

BuildRoot には次の %{_tmppath}/ を設定しなければなりません。そして少なくとも %{name}、%{version} や %{release} を含まなければなりません。これは全てのシステム上で存在することが保証されているので mktemp を実行するかもしれません。そこから、パッケージャは1つの健全な BuildRoot を使用することを期待します。

BuildRoot タグのための 推奨設定 は次の通りです(優先される設定の降順に記載します)。

%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%{_tmppath}/%{name}-%{version}-%{release}-root

よく分からなければ、1番上のものを選択してください。

%install のために BuildRoot を設ける

あなたのパッケージの %install セクションの中で適切な BuildRoot を準備することは重要です。それは EPEL5 の rpm や次のモノはこの設定を自動的に行わないからです。これらのリリース向けのパッケージは、いずれにせよ %install セクションを持たなければなりません。

%install
rm -rf %{buildroot}

又は

%install
rm -rf $RPM_BUILD_ROOT

これは %install セクションで BuildRoot が作り直されることを保証します。

競合するパッケージに対するポリシー

• EPEL パッケージは RHEL ベース(アドバンスドプラットホームを含む)のパッケージと決して競合してはいけません。
• EPEL パッケージはその他の RHEL チャンネルのパッケージと競合しても良いです。
• EPEL メンテナは RHEL メンテナとコミュニケーションを取るべきです。特定パッケージをリリースしないことや、基本的にはその時その時の、あるチャンネルの競合パッケージをうまく扱うために EPEL のパッケージを調整することによって対応するようにしてください。

EPEL に既に存在するパッケージが RHEL へ追加される場合、我々はそのパッケージが EPEL からアップデートされるのをブロックする必要があります。この手順は次の通りです。

• パッケージが追加された EL バージョン向けの cvs ブランチにあるそのパッケージを 'dead.package' する
• 同一ブランチ向けの pkgdb を破棄する
• そのパッケージをブロックするために rel-eng でチケットを登録する