EPEL/GuidelinesAndPolicies/ja

In other languages: English (en) 日本語 (ja) 中文（中国大陆） (zh-cn) [edit]

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

EPELのパッケージは、Fedoraのパッケージガイドラインとメンテナンスガイドラインに従います。ガイドラインとは、パッケージングガイドラインに限定されず、パッケージ命名ガイドライン と パッケージレビューガイドライン を含みます。これらは、 Fedora運営委員会 と パッケージング委員会 が設計し、保守管理しています。EPEL特有の例外は、本ガイドラインと EPEL:Packaging のページに文書化されています。

「ガイドライン」と「ポリシー」の各セクションでは、意図的にそれらの名前を使用しています。ガイドラインとは通常守られるべきものであると考えていますが、理由があればそうする必要はありません -- あなたの理由が正しいかどうか疑わしい場合はEPEL SIGメンバーに尋ねてください。 「ポリシー」とはガイドラインよりも強い意味を持っており、そのセクションに書かれていることは常に従わなければならない規則と考えられるべきです。

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

EPELは、私たちのリポジトリのユーザーに共通の「見た目と使い勝手」を提供したいと考えています。そのため、EPEL SIGは、EPELでのパッケージ保守管理と更新のための規則を記述するこのポリシーを書きました。それらは現在Fedoraにあるものより少し厳しく規制されています。

要約

EPELの目的は、EPELレポジトリのパッケージを、そのパッケージの邪魔をしたり置き換えたりすることなく、そのパッケージがビルドされたEnterprise Linuxディストリビューションの質を高めるすることです。リポジトリ内のパッケージは、可能であれば、それらがビルドされたエンタープライズパッケージと同様の方法で保守管理する必要があります。言い換えれば、レポジトリ内のパッケージ群は、通常はまったく変更されず、正当な理由がある場合にのみ変更される、ほとんど安定したパッケージのセットです。つまり、「ねえ、新しいバージョンがあるんだけど、ビルドして、出荷しようよ」という考え方はありません。

ポリシー

EPELパッケージは、それらがビルドされたEnterprise Linuxディストリビューションの質を高めるだけで、邪魔することはありません。したがって、EPELからのパッケージは、ターゲットディストリビューションからのパッケージ（基本ディストリビューション上のものやレイヤードプロダクトを含む）を決して置き換えてはいけません。カーネルモジュールにいたっては、許可されていません。なぜならそれらは基本カーネルを乱すことがあるからです。

各ディストリビューションのターゲットベースは、古いメーリングリストでの議論で、Koji BuilderがアクセスできるRed Hat Enterprise Linuxのバージョンとして定義されています。

• EPEL-6は、Red Hat Enterprise Linux 6チャンネルに対してビルドされています
  • dist-6E-Server
  • dist-6E-Server-ha
  • dist-6E-Server-optional
  • dist-6E-Server-lb
• EPEL-7は、Red Hat Enterprise Linux 7チャンネルに対してビルドされています
  • rhel7-server
  • rhel7-rhel-extras
  • rhel7-server-ha
  • rhel7-server-optional

他のRed Hat Enterprise Linuxチャンネルにあることが知られているパッケージは、アーキテクチャが限定されているパッケージと同様の方法で保守管理する必要があります。パッケージはソフトウエア開発元（RHEL-6の場合はftp.redhat.com、RHEL-7の場合はgit.centos.org）から入手し、Red Hat Enterprise Linuxリリースのものよりも絶対に少なくしてください。これは、パッケージがワークステーションチャネルからサーバチャネルに移動することが知られており、パッケージを反対に移動することが問題になる可能性があるためです。

リポジトリ内のパッケージは、可能であれば、それらがビルドされたエンタープライズパッケージと同様の方法で保守管理する必要があります。言い換えれば、通常はまったく変更されず、変更に正当な理由がある場合にのみ変更される、ほとんど安定したパッケージのセットを用意します。これは安定したエンタープライズ環境の精神です。

避けられない変更は異なるリリースツリーにルーティングされます。重要なバグを修正したアップデート（たとえば、データの破損、セキュリティの問題、本当に厄介なバグ）だけが短期間テスト用ブランチに行き、その後安定版ブランチにプッシュされます。 EPELパッケージに署名して公開リポジトリにプッシュする人々は、安定版リポジトリ用の更新パッケージのリストにざっと目を通し、「安定版ブランチ用の重要な更新のみ」という目標が確実に満たされるようにします。

その他の更新は、時間が経つにつれてtestingレポジトリに入れられます。このリポジトリは、少なくとも2週間のテストの後、新しい安定版ブランチになります。 しかし、これらの更新でさえも可能な限り修正に限定されるべきであり、可能であれば事前にFedoraでテストされるべきです。可能であれば、ABIを変更したり設定ファイルの調整を必要とするアップデートパッケージは避けなければなりません。 ABIを変更するパッケージの更新を回避する方法がない場合は、古いABIを提供する互換パッケージをリポジトリで提供する必要があります。依存関係の問題がある場合や、メンテナが安定しているとメンテナが感じていない場合は、testingリポジトリ内のパッケージは、安定版レポジトリへのプッシュは妨げられます。パッケージ保守管理者は2週間後に彼らのパッケージを安定版にするように要求するか、そうするために彼らのアップデートに十分なカルマを持っている必要があることに注意してください。testingレポジトリから安定版レポジトリへの自動昇格は行われません。

新しい四半期ごとのアップデートがリリースされると、EPELはそのアップデートのCentOSバージョンが利用可能になるまで待ちます。

パッケージの最小テスト時間を含む、EPELパッケージの更新に関する詳細は、 EPEL Updates Policyを参照してください。

パッケージビルド＆更新業務の流れ（例） / 情報

• パッケージ保守管理者は、通常 'make build'を使ってパッケージをビルドします。
• パッケージ保守管理者は、bodhiを使ってアップデート要求を送信します（ 'make update'またはウェブインタフェースを介して）。
• セキュリティ上の問題または重大なバグ修正でない限り、アップデートは少なくとも2週間のtestingレポジトリに置かれます。
• 2週間後、bodhiはパッケージ保守管理者にそれが2週間であることを知らせるためにメールを送ります。
• この時点でパッケージ保守管理者が安定版を要求している場合、または更新に十分なカルマがある場合は、次のプッシュで安定版にプッシュされます。
• testingと安定版の両方のためのプッシュは毎日行われます。
• メンテナがそれを要求しない限り、あるいは十分なカルマがない限り、更新は決してtestingレポジトリを離れて安定版レポジトリに行くことはありません（自動的にアップデートが安定版リポジトリへ追加されません）。

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

どのようなパッケージ更新がうまくいったかどうかの例

実際に上述したポリシーを適用するためのやり方の概略を例示します。きっと役立つでしょう。

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

パッケージfooがEPEL 5.0のバージョン1.0.1として出荷されたとしましょう。ソフトウエア開発元の開発者は、現在1.0.2を出荷しています

• 通常どおりにビルドしますが、テストには少なくとも2週間、おそらくそれ以上かかります。

もう少し大きいマイナーバージョンアップデート

パッケージfooがEPEL 5.0のバージョン1.0.1として出荷されたとしましょう。ソフトエウア開発元の開発者は、現在1.2.0を出荷しています。 ABIは1.0.1と互換性があり、既存の設定ファイルは引き続き機能します。

• 通常どおりにビルドしますが、安定版に移行するのに十分なカルマが存在するまでテストを続けます。

もう一度、もう少し大きいマイナーバージョンのアップデート

パッケージfooがEPEL 5.0のバージョン1.0.1として出荷されたとしましょう。ソフトウエア開発元の開発者は現在1.4.0を出荷しています。 ABIは1.0.1と互換性がありますが、設定ファイルは手動調整が必要です。

• 安定版ブランチ用のビルドは通常受け入れられません。修正しなければならない重大なバグがある場合は、バックポートを強く考慮する必要があります。
• テストブランチ用のビルドも好まれません。しかし、重大なバグを解決するための簡単な方法が他にない場合は問題ありません。しかし、アップデートと設定ファイルの調整は適切にユーザにアナウンスされる必要があります - これにはepel-announceリストを使用してください。
• できるだけ、testingリポジトリに長く留めてください。

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

パッケージfooがEPEL 5.0のバージョン1.0.1として出荷されたとしましょう。ソフトエア開発元の開発者は現在2.0.0を出荷しています。 ABIの変更や設定ファイルの手動調整が必要です。

• 可能であれば、この更新は避けるべきです。重大なバグを修正する方法が他にない場合は、テストブランチ用に新しいバージョンをビルドして、次のアップデートのためのリリースノートでアップデートと必要な調整について言及することが受け入れられることはまれです。 ABIが変更された場合は、古いライブラリとの追加の互換パッケージが必要です。

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

セキュリティアップデートはbodhiでそのようにマークされるべきであり、安定版にプッシュされます。このため、これらの種類の更新では、できるだけ少ない変更を試みるようにしてください。バックポートされた修正のみを適用するか、必要な場合は修正のみを提供する新しいバージョンを適用します。セキュリティ更新プログラムで他の変更をプッシュしないようにしてください。

より多くの例を追加し表示する

表示される数が多すぎる場合は、それらを別の文書に入れてください。

パッケージがEPELに適しているかまだ自信がない？

EPEL SIGメンバーからの意見を、EPEL開発者メーリングリストまたはfreenode.org の #epel で尋ねてください。

Fedora Extrasのような最新のパッケージを含む継続的なリリースでは理由は？

なぜ私たちはそうすべきなのでしょうか？最新パッケージを使った継続的リリースとは、Fedora Extrasがしたこと、そしてうまくいったこと、そしてうまくいっています。 - しかし、それは主にFedora（Core）がたくさんのアップデートとほぼ継続的なリリース制度/高速なリリース周期を持っているためです。しかし、私たちがビルドしているEnterprise Linuxは、更新にもっと注意を払い、ライフサイクルが長くなります。そのため、EPELについても同じことを行うべきです。なぜなら、彼らが何らかの理由で安定したディストリビューションを選んだからです - 最新のパッケージが欲しいなら、Fedoraを選んだことでしょう。

確かに、安定した基盤とその上に新しい一連のパッケージを混在させることが望まれる分野はたくさんあります。 *おそらく* EPELプロジェクトは長期的にこれらのケースのための解決策を（慎重に更新されたリポジトリと並行して）提供するでしょうが、それが本来の目的ではありません。この方向に何かを提供するサードパーティのリポジトリがすでにそこにあるので、ユーザはすでにそれらによって提供されているかもしれません。

さらにFedora Extrasのような継続的なリリース制度は、他の理由で多くのEPELパッケージでは不可能です。新しいパッケージはしばしば新しいバージョンのあるコアライブラリを必要とします。これはEPELで問題を引き起こします。コアOSのライブラリに代わるものとして更新されたライブラリを提供することができないからです。

例：この文書は、RHEL5がリリースされた頃に作成されました。 RHEL5用にビルドされる多くのパッケージは、現時点ではまだRHEL4用にビルドすることはできません。RHEL4-gtk2-Packageは2年前にリリースされています。新しいgtk2に依存するため現在の多くのアプリケーションには古すぎるからです。 したがって、まったく新しいパッケージを使った継続的な制度を作ろうとしても失敗するでしょう。このライブラリ群への依存のためにたくさんのパッケージをビルドすることはできないからです。 結局、他のものはまだかなり古いものですが、私たちはいくつかの非常に新しいパッケージのレポジトリを持つことになりますが、その組み合わせでは、「最新バージョン」と「慎重なアップデートのみ」のどちらの面も満足できないでしょう。 そのため、「慎重な更新のみ」の側面をターゲットにしています。 EPELのサポートとアップデートの周期はFedorよりずっと長いことを忘れないでください。

EPELでFedoraパッケージを入手する

ここでEPELでFedoraパッケージを入手するために使用される手順についてを見てください。

配布に特有のガイドライン

Fedoraパッケージングガイドラインは現在のFedoraリリース向けに書かれています。時にはFedoraに変更があり、RHELで実行されている古いソフトウェアに対してパッケージングガイドラインが意味を成さないようにします。それが起こるとき、私たちはEPEL:PackagingページのFedora Packaging Guidelinesとの違いを文書化します。

衝突するパッケージの方針

RHELリリースパッケージごとの競合チャンネルの除外

• EPELパッケージは、RHEL Base（Advanced Platformを含む）のパッケージと競合してはいけません。 EPELと競合しないRHELリリースごとのチャネルの完全なリストについては、上記のリンクを参照してください。これは、kojiが外部リポジトリからのパッケージを扱う方法によるソースパッケージ名を含みます。
• EPELパッケージは、他のRHELチャンネルのパッケージと競合する可能性があります。
• EPELパッケージ保守管理者は、RHEL保守管理者からのコミュニケーションを受け入れ、特定のパッケージを出荷しないことによって、またはケースに応じて、チャネル内の競合するパッケージをより適切に処理するようにEPELでパッケージを調整することによってそれらを試みて対応します。

パッケージがすでにEPELに入っているためにRHELに追加する場合は、通常EPELから削除する必要があります。これを行うには、除外プロセスに従ってください。パッケージがすべてのアーキテクチャのサブセットにしか利用できない場合でも、EPEL Packaging Guidelinesで説明されているように、パッケージをEPELに保持することは依然として可能です。

互換パッケージの衝突

下位互換性を維持するというEPELポリシーにより、EPELはFedoraよりも前方互換パッケージの必要性が高くなっています。 互換パッケージを作成するとき、 Conflicts Guidelinesで説明されているように、それらの間にConflictsを設定しても構いません。 現時点では、これはEPELのパッケージをオーバーライドするパッケージに対してのみ許可されており、RHEL Baseでは許可されていません。