From Fedora Project Wiki
m (リンク切れ修正)
 
(19 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{autolang}}
= EPEL 向けのパッケージングガイドラインとポリシー =
= EPEL 向けのパッケージングガイドラインとポリシー =


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


 
「ガイドライン」と「ポリシー」の各セクションでは、意図的にそれらの名前を使用しています。ガイドラインとは通常守られるべきものであると考えていますが、理由があればそうする必要はありません -- あなたの理由が正しいかどうか疑わしい場合はEPEL SIGメンバーに尋ねてください。 「ポリシー」とはガイドラインよりも強い意味を持っており、そのセクションに書かれていることは常に従わなければならない規則と考えられるべきです。
EPEL におけるパッケージングは Fedora のパッケージングとメンテナンスガイドラインに従います。[[Development/SteeringCommittee|  FESCo]] と[[Packaging/Committee|パッケージング委員会]]によってメンテナンスされた[[Packaging/Guidelines|パッケージングガイドライン]]、[[Packaging/NamingGuidelines|パッケージ名ガイドライン]]、[[Packaging/ReviewGuidelines|パッケージレビューガイドライン]]、そして[[Extras/Policies|パッケージングポリシー]]になりますが、それらに制限されたものではありません。次のような EPEL に特化した例外事項もあります。
 
"ガイドライン" と "ポリシー" のセクションはわざとそのような名前を使用していることに注意してください。''ガイドライン''は通常守るべき内容と考えてください。しかし、そうしない理由が何かあるなら守る必要はありません。その理由が適切かどうか疑問に思ったら EPEL SIG メンバーへ尋ねてください。"ポリシー"という言葉には強い意味があります。そのセクションに記載された内容は必ず守らなければならないルールと考えてください。


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


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


=== ダイジェスト ===
=== 要約 ===
<!-- INCLUDEPOLICYFRONTSTART
<!-- INCLUDEPOLICYFRONTSTART
-->
-->


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


<!-- INCLUDEPOLICYFRONTEND
<!-- INCLUDEPOLICYFRONTEND
Line 24: Line 24:
=== ポリシー ===
=== ポリシー ===


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


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


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


Other updates get queued up in a testing repository over time. That
他のRed Hat Enterprise Linuxチャンネルにあることが知られているパッケージは、アーキテクチャが限定されているパッケージと同様の方法で保守管理する必要があります。パッケージはソフトウエア開発元（RHEL-6の場合はftp.redhat.com、RHEL-7の場合はgit.centos.org）から入手し、Red Hat Enterprise Linuxリリースのものよりも絶対に少なくしてください。これは、パッケージがワークステーションチャネルからサーバチャネルに移動することが知られており、パッケージを反対に移動することが問題になる可能性があるためです。
repository becomes the new stable branch after at LEAST 2 weeks of testing.  
But even these updates should be limited to fixes only as far as possible and should
be tested in Fedora beforehand if possible. Updated Packages that
change the ABI or require config file adjustments must be avoided if
at all possible. Compat- Packages that provide the old ABI need to be
provided in the repo if there is no way around a package update that
changes the ABI. Packages in the testing repo that contain dependency
issues or where the maintainer doesn't feel they are stable will be
held back from the stable push. Note that maintainers will need to request
their packages go to stable after 2 weeks or have sufficent karma in their update
to do so. No automatic promotions from testing to stable happen any longer.  


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


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


* Maintainer builds the package normally using 'make build'
その他の更新は、時間が経つにつれてtestingレポジトリに入れられます。このリポジトリは、少なくとも2週間のテストの後、新しい安定版ブランチになります。
* The Maintainer submits an update request using bodhi ('make update' or via the web interface).
しかし、これらの更新でさえも可能な限り修正に限定されるべきであり、可能であれば事前にFedoraでテストされるべきです。可能であれば、ABIを変更したり設定ファイルの調整を必要とするアップデートパッケージは避けなければなりません。 ABIを変更するパッケージの更新を回避する方法がない場合は、古いABIを提供する互換パッケージをリポジトリで提供する必要があります。依存関係の問題がある場合や、メンテナが安定しているとメンテナが感じていない場合は、testingリポジトリ内のパッケージは、安定版レポジトリへのプッシュは妨げられます。パッケージ保守管理者は2週間後に彼らのパッケージを安定版にするように要求するか、そうするために彼らのアップデートに十分なカルマを持っている必要があることに注意してください。testingレポジトリから安定版レポジトリへの自動昇格は行われません。
* The update MUST spend at least 2 weeks in testing, unless it's a security or critical bug fix.
* After 2 weeks, bodhi will mail the maintainer to let them know it's been 2 weeks.
* If the Maintainer requests stable at this point or the update has sufficent karma it will be pushed to stable in the next push.
* Testing pushes take place nearly daily. Stable pushes happen bi-weekly on tuesdays.
* Updates never leave testing for stable unless the maintainer requests it, or there is sufficent karma. (NO autopromotion of updates).


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


==== パッケージを更新して良いかどうかの例 ====
パッケージの最小テスト時間を含む、EPELパッケージの更新に関する詳細は、[[EPEL_Updates_Policy| EPEL Updates Policy]]を参照してください。


Examples hopefully help to outline how to actually apply above policy
=== パッケージビルド＆更新業務の流れ（例） / 情報 ===
in practise.


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


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


===== マイナーバージョンアップより少しだけ大きな修正の再更新 =====
* 通常どおりにビルドしますが、テストには少なくとも2週間、おそらくそれ以上かかります。


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
パッケージfooがEPEL 5.0のバージョン1.0.1として出荷されたとしましょう。ソフトエウア開発元の開発者は、現在1.2.0を出荷しています。 ABIは1.0.1と互換性があり、既存の設定ファイルは引き続き機能します。
* 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.
パッケージfooがEPEL 5.0のバージョン1.0.1として出荷されたとしましょう。ソフトウエア開発元の開発者は現在1.4.0を出荷しています。 ABIは1.0.1と互換性がありますが、設定ファイルは手動調整が必要です。


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


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.


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


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


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


=== 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
===  パッケージがEPELに適しているかまだ自信がない？ ===
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
EPEL SIGメンバーからの意見を、[http://www.redhat.com/archives/epel-devel-list/ EPEL開発者メーリングリスト]またはfreenode.org の #epel で尋ねてください。
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
=== Fedora Extrasのような最新のパッケージを含む継続的なリリースでは理由は？ ===
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.


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


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


=== ディストリビューションに特化したガイドライン ===
さらにFedora Extrasのような継続的なリリース制度は、他の理由で多くのEPELパッケージでは不可能です。新しいパッケージはしばしば新しいバージョンのあるコアライブラリを必要とします。これはEPELで問題を引き起こします。コアOSのライブラリに代わるものとして更新されたライブラリを提供することができないからです。
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 ====
例：この文書は、RHEL5がリリースされた頃に作成されました。 RHEL5用にビルドされる多くのパッケージは、現時点ではまだRHEL4用にビルドすることはできません。RHEL4-gtk2-Packageは2年前にリリースされています。新しいgtk2に依存するため現在の多くのアプリケーションには古すぎるからです。 したがって、まったく新しいパッケージを使った継続的な制度を作ろうとしても失敗するでしょう。このライブラリ群への依存のためにたくさんのパッケージをビルドすることはできないからです。 結局、他のものはまだかなり古いものですが、私たちはいくつかの非常に新しいパッケージのレポジトリを持つことになりますが、その組み合わせでは、「最新バージョン」と「慎重なアップデートのみ」のどちらの面も満足できないでしょう。 そのため、「慎重な更新のみ」の側面をターゲットにしています。 EPELのサポートとアップデートの周期はFedorよりずっと長いことを忘れないでください。
<ul>
<li>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.</li>
<li>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:
<pre>
%{__python} setup.py install --skip-build --root $RPM_BUILD_ROOT
%{__python} setup.py install -O1 --skip-build --root $RPM_BUILD_ROOT
</pre></li>
</ul>


==== エンタープライズ Linux 5 ====
{{Anchor|nomaintainerresponse}}
<ul>
<li>rpm in EPEL5 and below does not automatically create dependencies for pkgconfig files.  Packages containing pkgconfig(.pc) files must <code>Requires: pkgconfig</code> (for directory ownership and usability).</li>
<li>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:
<ol>
<li>Rename scripts in %{_bindir} to not have a .py extension:  For instance, from /usr/bin/orient.py to /usr/bin/orient.</li>
<li>Use %exclude to exclude the scripts from the file listing:
<pre>
%files
%{_bindir}/orient.py
%exclude %{_bindir}/orient.pyc
%exclude %{_bindir}/orient.pyo
</pre></li>
</ol>
</li>
</ul>


==== BuildRoot タグ ====
=== EPELでFedoraパッケージを入手する ===


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.
[[Getting_a_Fedora_package_in_EPEL|ここでEPELでFedoraパッケージを入手するために使用される手順について]]を見てください。


The ''BuildRoot'' value MUST be below <code>%{_tmppath}/</code> and MUST contain at least <code>%{name}</code>, <code>%{version}</code> and <code>%{release}</code>. It may invoke <code>mktemp</code> 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) :
[[Packaging:Guidelines|Fedoraパッケージングガイドライン]]は現在のFedoraリリース向けに書かれています。時にはFedoraに変更があり、RHELで実行されている古いソフトウェアに対してパッケージングガイドラインが意味を成さないようにします。それが起こるとき、私たちは[[EPEL:Packaging]]ページのFedora Packaging Guidelinesとの違いを文書化します。
<pre>
%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%{_tmppath}/%{name}-%{version}-%{release}-root
</pre>
If unsure, simply pick the first.


{{Anchor|PreppingBuildRootForInstall}}
[[Category:EPEL]]
==== %install のために BuildRoot を設ける ====
It is important to properly prepare the ''BuildRoot'' in the <code>%install</code> 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:
 
<pre>
%install
rm -rf %{buildroot}
</pre>


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


<pre>
[[EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F|RHELリリースパッケージごとの競合チャンネルの除外]]
%install
rm -rf $RPM_BUILD_ROOT
</pre>
 
This is to ensure that the ''BuildRoot'' will be created fresh during the <code>%install</code> section.
 
 
[[Category:EPEL]]


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


* EPEL packages must never conflict with packages in RHEL Base (Including Advanced Platform).
パッケージがすでにEPELに入っているためにRHELに追加する場合は、通常EPELから削除する必要があります。これを行うには、[[How_to_remove_a_package_at_end_of_life|除外プロセス]]に従ってください。パッケージがすべてのアーキテクチャのサブセットにしか利用できない場合でも、[[EPEL:Packaging＃Limited_Arch_Packages|EPEL Packaging Guidelines]]で説明されているように、パッケージをEPELに保持することは依然として可能です。
* 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
下位互換性を維持するというEPELポリシーにより、EPELはFedoraよりも前方互換パッケージの必要性が高くなっています。 互換パッケージを作成するとき、[[Packaging:Conflicts＃Compat_Package_Conflicts | Conflicts Guidelines]]で説明されているように、それらの間にConflictsを設定しても構いません。 現時点では、これはEPELのパッケージをオーバーライドするパッケージに対してのみ許可されており、RHEL Baseでは許可されていません。
* retire in pkgdb for the same branch
* file a ticket with [https://fedorahosted.org/rel-eng rel-eng] to block it.

Latest revision as of 07:20, 12 May 2019

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では許可されていません。

Retrieved from "https://fedoraproject.org/w/index.php?title=EPEL/GuidelinesAndPolicies/ja&oldid=543067"