From Fedora Project Wiki
Line 86: Line 86:
=== EPEL 向けにパッケージを提供して良いかどうか自信がない ===
=== EPEL 向けにパッケージを提供して良いかどうか自信がない ===


Just ask on [http://www.redhat.com/archives/epel-devel-list/ EPEL developers mailing list] or #epel on freenode.org for opinions from EPEL SIG members.
[http://www.redhat.com/archives/epel-devel-list/ EPEL 開発者メーリングリスト]か、freenode.org の #epel チャンネルで尋ねてみて EPEL SIG メンバーから意見をもらうようにしてください。


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

Revision as of 06:32, 6 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 で行っていたように最新パッケージでリリースを行わないのはなぜですか?

Why should we? That would be what Fedora Extras did and worked and works well for it -- but that's mainly because Fedora (Core) has lots of updates and a nearly rolling-release scheme/quick release cycle, too. But the Enterprise Linux we build against is much more careful with updates and has longer life-cycle; thus we should do the same for EPEL, as most users will properly prefer it that way, as they chose a stable distro for some reasons -- if they want the latest packages they might have chosen Fedora.

Sure, there are lots of areas where having a mix of a stable base and a set of quite new packages on top of it is wanted. *Maybe* the EPEL project will provide a solution (in parallel to the carefully updated repository!) for those cases in the long term, but not for the start. There are already third party repositories out there that provide something in this direction, so users might be served by them already.

Further: A rolling release scheme like Fedora Extras did is not possible for many EPEL packages for another reason, new packages often require new versions of certain core libraries. This will cause problems in EPEL because we won't be able to provide updated libs as it would replace libraries in the core OS.

Example: This document was written round about when RHEL5 got released; many packages that get build for RHEL5 can't be build for RHEL4 at this point of time already, as the RHEL4-gtk2-Package is two years old and is to old for many current applications, as they depend on a newer gtk2. So if even if we would try to have a rolling scheme with with quite new package we'd fail, as we can't build a bunch of package due to this dependencies on libs; in the end we would have a repo with some quite new packages while others are still quite old. That mix wouldn't make either of the "latest versions" or "careful updates only" sides happy; so we try to target the "careful updates only" sides. Remember, EPEL's support and updates cycle is much longer then Fedora's.

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

Look here for the procedure used to get a Fedora package in EPEL.

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

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.