From Fedora Project Wiki
Line 102: Line 102:
=== EPEL から Fedora パッケージを取得する ===
=== EPEL から Fedora パッケージを取得する ===


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


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

Revision as of 04:06, 7 June 2010

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 パッケージを取得する手続きをご覧ください。

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

EL 5 and earlier do not support noarch subpackages. If your build fails due to unpackaged debuginfo files ensure that the BuildArch: noarch is wrapped in an if to make sure its not used on EL-5 and earlier.

エンタープライズ Linux 4

  • EPEL4 Python packages should manually depend on the proper python version that it was build for. Most old FC-3 python packages should still use this trick.
  • EPEL4 Python packages need to generate .pyc and .pyo files in the spec file. If your module is using distutils or setuptools, use the following commands during %install:
    %{__python} setup.py install --skip-build --root $RPM_BUILD_ROOT
    %{__python} setup.py install -O1 --skip-build --root $RPM_BUILD_ROOT
    

エンタープライズ Linux 5

  • rpm in EPEL5 and below does not automatically create dependencies for pkgconfig files. Packages containing pkgconfig(.pc) files must Requires: pkgconfig (for directory ownership and usability).
  • in EPEL5 the automatic byte compilation of python files that is performed by brp-python-bytecompile byte compiles all files that match *.py This is undesirable for program files in %{_bindir} and %{_sbindir} because the user will probably never invoke these files, only the main program file and python won't use these files. Until the bug is resolved, there are two workarounds:
    1. Rename scripts in %{_bindir} to not have a .py extension: For instance, from /usr/bin/orient.py to /usr/bin/orient.
    2. Use %exclude to exclude the scripts from the file listing:
      %files
      %{_bindir}/orient.py
      %exclude %{_bindir}/orient.pyc
      %exclude %{_bindir}/orient.pyo
      

BuildRoot タグ

rpm in EPEL5 and below does not automatically provide a value for the BuildRoot tag, so one must be provided in the spec by the packager.

The BuildRoot value MUST be below %{_tmppath}/ and MUST contain at least %{name}, %{version} and %{release}. It may invoke mktemp since this is guaranteed to exist on every system. From there, packagers are expected to use a sane BuildRoot.

The recommended values for the BuildRoot tag are (in descending order of preference) :

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

If unsure, simply pick the first.

%install のために BuildRoot を設ける

It is important to properly prepare the BuildRoot in the %install section of your package before it is used as rpm in EPEL5 and below does not do this automatically. Package for these releases MUST have an %install section that begins with either:

%install
rm -rf %{buildroot}

or

%install
rm -rf $RPM_BUILD_ROOT

This is to ensure that the BuildRoot will be created fresh during the %install section.

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

  • EPEL packages must never conflict with packages in RHEL Base (Including Advanced Platform).
  • EPEL packages can conflict with packages in other RHEL channels.
  • EPEL maintainers should be open to communication from RHEL maintainers and try and accommodate them by not shipping specific packages, or by adjusting the package in EPEL to better handle a conflicting package in a channel on a case by case basis.

When a package is added to RHEL that is already in EPEL, we need to block it from being updated in EPEL. Follow these steps to do that:

  • 'dead.package' it in the cvs branch for the EL version where the package has been added
  • retire in pkgdb for the same branch
  • file a ticket with rel-eng to block it.