From Fedora Project Wiki
Line 40: Line 40:
 
* セキュリティやクリティカルなバグ修正でない限り、アップデートは少なくとも2週間テストリポジトリに置かれなければなりません。
 
* セキュリティやクリティカルなバグ修正でない限り、アップデートは少なくとも2週間テストリポジトリに置かれなければなりません。
 
* 2週間後、bodhi からメンテナへ2週間経過したことを知らせるメールが届くでしょう。
 
* 2週間後、bodhi からメンテナへ2週間経過したことを知らせるメールが届くでしょう。
* この時点でメンテナがそのパッケージが安定している、又は十分なカルマを体得していると判断して安定版リポジトリへの追加リクエストをするなら、次回のアップデートの追加時に安定版リポジトリへ追加されます。
+
* この時点でメンテナがそのパッケージが安定している、又は十分なカルマを体得して安定版リポジトリへの追加リクエストをするなら、次回のアップデートの追加時に安定版リポジトリへ追加されます。
 
* テストリポジトリへの追加はほぼ毎日行われます。安定版リポジトリへの追加は隔週の火曜日に行われます。
 
* テストリポジトリへの追加はほぼ毎日行われます。安定版リポジトリへの追加は隔週の火曜日に行われます。
* アップデートはメンテナが追加リクエストを行う、又は十分なカルマを体得していると判断しない限り、決してテストリポジトリから安定版リポジトリへ追加されません。(自動的にアップデートが安定版リポジトリへ追加されません)
+
* アップデートはメンテナが追加リクエストを行う、又は十分なカルマを体得していない限り、決してテストリポジトリから安定版リポジトリへ追加されません。(自動的にアップデートが安定版リポジトリへ追加されません)
  
 
=== このポリシーのガイドラインと背景 ===
 
=== このポリシーのガイドラインと背景 ===

Revision as of 05:31, 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週間経過したことを知らせるメールが届くでしょう。
  • この時点でメンテナがそのパッケージが安定している、又は十分なカルマを体得して安定版リポジトリへの追加リクエストをするなら、次回のアップデートの追加時に安定版リポジトリへ追加されます。
  • テストリポジトリへの追加はほぼ毎日行われます。安定版リポジトリへの追加は隔週の火曜日に行われます。
  • アップデートはメンテナが追加リクエストを行う、又は十分なカルマを体得していない限り、決してテストリポジトリから安定版リポジトリへ追加されません。(自動的にアップデートが安定版リポジトリへ追加されません)

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

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

Examples hopefully help to outline how to actually apply above policy in practise.

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

Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1; upstream developers now ship 1.0.2

  • build as normal, but wait at least two weeks and possibly more in testing.
マイナーバージョンアップよりは少しだけ大きな修正

Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1; upstream developers now ship 1.2.0; the ABI is compatible to 1.0.1 and the existing config files continue to work

  • build as normal, but leave in testing until there is sufficent karma to go to stable.
マイナーバージョンアップより少しだけ大きな修正の再更新

Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1; upstream developers now ship 1.4.0; the ABI is compatible to 1.0.1, but the config files need manual adjustments

  • build for the stable branch is normally not acceptable; a backport should be strongly considered if there are any serious bugs that must be fixed
  • build for the testing branch is also disliked; but it is acceptable if there is no other easy way out to solve serious bugs; but the update and the config file adjustments need to be announced to the users properly -- use the epel-announce list for this.
  • leave in testing if at all possible.
メジャーバージョンアップ

Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1; upstream developers now ship 2.0.0; the ABI changes or the config files need manual adjustments

  • this update should be avoided if possible at all. If there really is no other way out to fix a serious bug then it rare cases it might be acceptable to build the new version for the testing branch and mention the update and the needed adjustments in the release notes for the next update. An additional compat- packages with the old libs is necessary if the ABI changed.
セキュリティアップデート

Security updates should be marked as such in bodhi and will be pushed to stable. Because of this you should always try and make as few changes as possible on these sorts of updates. Apply only the backported fix, or if you must, the new version that provides only the fix. Try and avoid pushing other changes with a security update.

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

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

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

Just ask on EPEL developers mailing list or #epel on freenode.org for opinions from EPEL SIG members.

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.