EPEL とは何？
エンタープライズ Linux 用の拡張パッケージ(EPEL) は、 Red Hat Enterprise Linux (RHEL) 向けの高品質なアドオンパッケージであり、CentOS や Scientific Linux (SL) のような RHEL からスピンオフしたディストリビューションと互換性のある、Fedora プロジェクトで有志によって作成されたパッケージになります。Fedora は RHEL のアップストリームであり、EPEL のアドオンパッケージは主に RHEL 向けにビルドされた Fedora リポジトリをソースとしています。
Fedora パッケージングコミュニティの一部として、EPEL パッケージは 100% フリーなオープンソースソフトウェアです(FLOSS)。
Fedora プロジェクトはどうして EPEL のスポンサーをしてるの？
多くの Fedora やエンタープライズ Linux の貢献者たちとユーザが EPEL パッケージを提供するために Fedora プロジェクトで作業したいと考えています。
Fedora プロジェクトは自分たちのインフラにも EPEL パッケージを使用しているので EPEL パッケージのユーザの1人です。Fedora プロジェクトは RHEL で提供されていないソフトウェアの一部が必要とされていることを知ることができるポジションにあり、また、そのことに関して何かをするための唯一のポジションでもあります。RHEL は Fedora から派生したものではありますが、RHEL に含まれるパッケージは Fedora から派生したパッケージの一部を商用サポートしているに過ぎません。EPEL プロジェクトのスポンサーになることによって Fedora の貢献者やユーザは多くの手段を得ることができます。
EPEL は Red Hat が商用サポートしてるの？
いいえ、していません。EPEL は Fedora コミュニティからの有志によって作成されたものです。ちょうど Fedora のように、Red Hat はこのプロジェクトのインフラをホスティングしていて、Red Hat のエンジニアはメンテナやリーダーとして関わりますが、EPEL パッケージには Red Hat が提供する SLA(Service Level Agreement) や商用サポートはありません。
EPEL プロジェクトが提供するパッケージは RHEL や互換ディストリビューションのどのリリース向けですか？
EPEL プロジェクトは RHEL 5.x と 4.x リリースと互換ディストリビューション(例えば CentOS)のアドオンパッケージを提供します。RHEL 3 や 2.1 向けのパッケージは、errata support policy によると、メンテナンスフェーズになるので提供されていません。Fedora をベースとするパッケージは、適切にメンテナンスするのが難しい RHEL 3 や 2.1 のリリースで利用できる古いバージョンのパッケージをビルドしないでしょう。
EPEL は RHEL や互換ディストリビューション向けの他のサードパーティリポジトリとどう違いますか？
- ほとんどの EPEL パッケージは Fedora リポジトリの同等パッケージから派生したものか、ビルドされたパッケージで、同じ人によってメンテナンスされています。エンドユーザからのフィードバックやテスト、仲間のレビューを通じて改良もされています。
- EPEL に付属するよく知られたドキュメントは Fedora パッケージングガイドラインは、RHEL が始めたものです。これは優れたインテグレーションであることを保証します。
- EPEL は純粋にフリーなアドオンリポジトリですが、RHEL や階層プロダクトのパッケージを置き換えるものではありません。
- EPEL はリポジトリをメンテナンスする Red Hat エンジニアと有志のコミュニティメンバーを含む大きな貢献者のチームがあります。
- EPEL は特許や法的問題がないフリーでオープンソースソフトウェアのみを提供します。
その他のリポジトリについて CentOS FAQ も参照してください。
EPEL パッケージは RHEL や互換ディストリビューションのみで利用可能なものですか？
パッケージは自由に利用可能です。プロジェクトの明確な目的は CentOS や Scientific Linux のような RHEL ベースのディストリジューションで利用できるようにすることです。
EPEL は RHEL や階層プロダクトが提供しているパッケージを置き換えるものですか？
いいえ、違います。EPEL はアドオンパッケージを提供するための純粋にフリーなリポジトリです。
EPEL に存在するパッケージの更新に関するポリシーはどのようなものですか？
詳細は EPEL パッケージのメンテナンスと更新ポリシーを参照してください。
Fedora プロジェクトは EPEL パッケージの品質をどのように保証しますか？
リポジトリへパッケージが追加される前に広範囲なパッケージングガイドラインの項目を満たしているかを仲間内でレビューします。唯一、重要なバグ修正の更新だけは直接的に安定板のリポジトリへ追加されます。その他の更新はエンタープライズ Linux の更新スケジュールと並行して、先ずテスト用のリポジトリへ置かれ、その後 EPEL の予定されたスケジュールに沿ってリリースされます。パッケージは Fedora でもよくテストされます。Fedora パッケージングガイドラインと QA チームは、このような全ての作業を支援して、エラーが発生しないように手伝ってくれます。また、さらに厳しい QA ポリシーのための議論も行います。どうか我々に加わって、協力してください。
EPEL パッケージはどのぐらいの期間に対して更新されていますか？
EPEL パッケージの更新は RHEL のリリースがサポートされている期間に対応するよう計画されています。現在の errata support policy によると、初期リリース後、7年間になります。
あるディストリビューション向けにビルドされたパッケージをそのディストリビューションのEOL(エンドオブライフ)までに誰かがパッケージをメンテナンスしてくれることを保証できますか？
唯一の確実な方法は、あなたがメンテナンスを行うことです。そもそも EPEL が始まった理由は偶然にもそういった経緯からです。
EPEL に存在するパッケージは基本的に有志でメンテナンスされています。パッケージが継続的に利用可能である状態をあなたが望むなら、直接、EPEL プロジェクトに参加してメンテナンスを行ってください。経験豊富なメンテナがあなたのパッケージのレビューを手伝ってくれるでしょう。そして、あなたはパッケージングについて学ぶことができます。あなたがそれをできるなら、職務欄の一部にパッケージング業務を書くことができます。職務欄へ追加するための基本事項は 一般的な作業内容に記載されている内容です。
リポジトリにあるパッケージのメンテナンスをしてくれる多くの貢献者と共にこの健全なプロジェクトにすることに全力を尽くしてきました。そして、作成されたリポジトリは全体として、RHEL がそのディストリビューションのバージョンのサポートを中止するまで続けられます。これは(現在では)7年間になります。7年間もの長期間に渡ると、色んな出来事が起こるでしょう。このプロジェクトの成功には、あなたの参加が不可欠です。
私の所属する ISV/IHV が EPEL にあるパッケージのメンテナンスを望む場合はどうなりますか？
ソフトウェアやハードウェアベンダは EPEL に参加することが推奨されます。詳細は ISV/IHV からの視点を参照してください。
EPEL を利用する
EPEL リポジトリからどうやってパッケージをインストールしますか？
RHEL4 と RHEL5 に RPM パッケージのリポジトリがあります。
リポジトリパッケージは yum や up2date を使用するための repo ファイルをインストールします。その後、EPEL リポジトリも含めて、通常の方法でパッケージをインストールすることができます。
su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm' ... su -c 'yum install foo'
リポジトリはどこにありますか？
EPEL パッケージは master mirror にあります。ミラーサイトは mirror list にあります。
どこでヘルプや報告されている問題を見つけることができます？
epel-devel-list や Freenode IRC の #epel チャンネルでヘルプや問題を議論することができます。bugzilla を通じて EPEL へ問題を報告してください。
どうやってそのパッケージが EPEL パッケージだと分かりますか？
全ての EPEL パッケージは EPEL gpg-key で署名されています。公開鍵 id 217521F6 は epel-release パッケージの一部です。yum は EPEL パッケージを最初にインストールするときに公開鍵をインポートするかをあなたに尋ねます。
EPEL は (Fedora Extras であったのような) の"アップストリーム" や "公式パッケージリポジトリ" ですか？
EPEL は RHEL や互換ディストリビューションの RPM パッケージの幾つかあるアドオンリポジトリの1つです。EPEL は公式リポジトリではありません。そういった違うリポジトリは違う目的やユーザベースを担います。
ちょうど RHEL 自身のような、実際の EPEL は Fedora がアップストリームであれば "ダウンストリーム" になります。EPEL は RHEL と同様、Fedora で常に開発、テスト、フィードバックを受けているパッケージを自身のプロダクトに取り込みます。Red Hat は Fedora プロジェクトへの資金援助や Red Hat メンテナの参加を通じて EPEL にも還元しますが、Red Hat が EPEL を保証したり、商用サポートすることはありません。
EPEL メンテナは EPEL が全てのニーズを満たすことができないということをよく分かっています。そのため、他のリポジトリが Fedora プロジェクトでは提供しないソフトウェアのために必要とされています。他のリポジトリでは、現在、ローリングリリースモデルによる EPEL 向けのパッケージか、フリーではない特許が関連するソフトウェアを提供します。
EPEL は repotags を利用しないのですか？
EPEL の初期に repotags を利用するかどうかについて、長時間の議論がありました。Fedora と EPEL の内外の多くのメンバーが、他のリポジトリのメンテナ同様、その議論に参加しました。その恩恵が不便な点を上回るような、本当の意味での同意が誰にも得られませんでした。その問題の一部には repotags が持っている(又はそれ以外)恩恵や不便な点について、議論に参加したメンバー同士で意見が一致しないことがあったからです。最終的に3回の投票(1回目は EPEL 運営委員会が発足する前の FESCo によるもの、後の２回は EPEL 運営委員会)を行って EPEL では repotags を利用しないことに決定しました。
あるパッケージが EPEL リポジトリのパッケージなら、どうやって分かりますか？
EPEL 由来のパッケージであるかどうかを調べるには、次のようなクエリを実行してください:
$ rpm -qp foo-0.1-5.el5.i386.rpm --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n'
foo-0.1-5.el5 Fedora Project
$ rpm -qp foo-0.1-5.el5.i386.rpm --qf '%{NAME}-%{VERSION}-%{RELEASE} %{DISTRIBUTION}\n'
foo-0.1-5.el5 Extras Packages for Enterprise Linux
$ rpm -qp foo-0.1-5.el5.i386.rpm --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SIGGPG}\n'
foo-0.1-5.el5 883f030500468e3e4e119cc036217521f611025863009f5fe424c6fe4bc81a57f45722e465e71381dda2f6009f7c08e1743794b5b9a5a4cd149081092801a5d935
あるいは、提供されたリポジトリの公開鍵で署名された全パッケージをリスト化する 'keychecker' スクリプトをインストールして実行することもできます。
EPEL は他のサードパーティリポジトリと協調しようとしますか？
EPEL はいつも他のチームやリポジトリと協調しようと議論していて、可能な限りそうするようにメンテナへ推奨しています。
他のサードパーティリポジトリとの互換性についてはどうですか？
もともと混在させるように設計されていない別々の RPM リポジトリを混在させると、yum や up2date による依存解決の問題を発生させる非互換な状態を招きます。ライブラリやアプリケーションが違うリポジトリから取得した場合、期待したように動作しないソフトウェアも時々あります。EPEL は RHEL や互換ディストリビューションへのアドオンリポジトリとして設計されています。問題を避けるための最善の方法は、同じシステム上で競合するパッケージを持つサードパーティリポジトリを EPEL と混在させないことです。そうは言っても、人によっては混在させたい場合もあるので、yum priorities プラグインが最悪の問題を避けるために役立つでしょう。
EPEL のパッケージが他のリポジトリと非互換、又は yum や up2date が依存解決中に失敗する問題に遭遇したなら、Bugzilla にバグ登録して、他のリポジトリのメンテナへも連絡を取るようにしてください。EPEL プロジェクトは問題解決のために自身のメンテナと他のリポジトリのメンテナと一緒になって、双方の側で受け入れられる解決策を探そうとします。しかしながら、そのような解決策がいつも見つかるという保証はありません。リポジトリ混在問題の技術的な解決策は、リポジトリの一方に障害や副作用をもたらすかもしれないからです。
EPEL への貢献
全般
どんな人が EPEL に貢献できるの？
誰もが EPEL に貢献できるでしょう。あなたが RHEL や互換ディストリビューションを使用していて、パッケージメンテナンスのスキルを持っているか自らそれらを学ぶ意欲があるなら、いつでもプロジェクトに参加してください。
Fedora プロジェクトで既に活動している貢献者向けへの質問
EPEL へパッケージを追加するにはどうすれば良いですか？
EPEL ブランチ(EL4, EL5, EL6 等)、タグ、ビルドにリクエストできるパッケージ以外は Fedora と同じプロセスに従う必要があります。
既存の Fedora パッケージのために EPEL ブランチをどうやってリクエストすれば良いですか？
パッケージ変更リクエスト で説明されている Fedora の通常方法に従ってください。あなたは自分のパッケージのバグレビューを使用することができます。あるいは、もしバグレビューを見つけられなかったら、そのパッケージのバグ登録を行って CVS リクエストのためにバグレビューを利用してください。あなたは Fedora メンテナでもあることを忘れないように注意してください。
私は Fedora でパッケージをメンテナンスしています。EPEL でも同様にメンテナンスしなければならないのですか？
いいえ。あなたがメンテナンスしたいならやってください。あるいは誰かに EPEL のパッケージのメンテナンスを依頼することもできます。時には EPEL であなたのパッケージをメンテナンスしたい EPEL のメンテナから連絡があるかもしれません。
私は Fedora でパッケージをメンテナンスしていて、EPEL でも同様にメンテナンスをしたいです。しかし、テストをするための RHEL サブスクリプションがありません
テストをするために RHEL の互換ディストリビューションを利用することできます。それは 100% 互換性があります。Fedora では Mock が利用可能で、パッケージをテストビルドするために使用される config ファイルが提供されています。
私は Fedora の貢献者で EPEL でも同様にメンテナンスをしたいです。私は何をしなければならなくて、EPEL プロジェクトは私に何を期待していますか？
全ての Fedora パッケージャは通常方法で CVS に EPEL ブランチをリクエストすることができます。自分のパッケージを EPEL でビルドするにあたって EPEL に特化したガイドラインとポリシーを承諾していると見なすので注意してください。また、EPEL のライフサイクル期間や数年間に及ぶ今後のパッケージメンテナンス計画を立てるべきです。RHEL のライフサイクルは7年間を予定していることを覚えておいてください。
あなたは自分の会社や組織で行うパッケージングの役割を正式なお仕事にしたいと考えるかもしれません。もし、そうできるなら、 一般的な作業内容が役に立つでしょう。自分の組織にパッケージング作業は価値があると認識されます。さらに新しい人がその役割になったとしても、組織内で継続的にパッケージをメンテナンスする人が必要であることが確認されます。
ビルド作業の前後におけるパッケージテストのために RHEL のサブスクリプション登録があるなら RHEL を、又は CentOS や Scientific Linux のようなフリーな互換ディストリビューションを利用してください。
EPEL と Fedora に存在するパッケージを分割しないようにするにはどうすれば良いですか？
1つのツリー(例えば、RHEL4)に適用されるパッケージの機能拡張が他のツリー(例えば、Fedora devel)へ追加されるように確認することに責任を持つ主メンテナを持つ計画があります。
このメンテナがどのような拡張方法が普通に理解出来るかを決定します。新たなリリース向けの RHEL ブランチは普通は RHEL リリースのベースにするための Fedora ブランチから作成されます。そのため、RHEL メンテナは Fedora にマージされた機能拡張を後で取り込むことに対して真面目に取り組んでいます。
Fedora から持ってきた私のパッケージは RHEL5 で何も変更せずシンプルにビルドしても良いですか？
多くのパッケージは何も変更せずにビルドできるでしょう。しかしながら、注意が必要なパッケージもあります。全てのビルドに必要な依存パッケージは RHEL5 か EPEL5 に含まれる必要があります。
もし EPEL のメンテナンスに興味がない Fedora の主パッケージャにレビュー済みのものであれば、あなたがこれらのパッケージをメンテナンスすることができます。あなたが per-repo メンテナとして EPEL 用のブランチをリクエストしてください。必ず Fedora パッケージャへ連絡するようにしてください。
また、RHEL Server では提供されていなくて、RHEL Desktop でのみ提供されているパッケージも幾つかあります。RHEL-ppc は Server しか提供されていないので BuildRequires として Desktop のみのパッケージを利用することができません。そのような場合、spec ファイルにアーキテクチャ独自の条件を追加する必要があるでしょう。
ここに Desktop でのみ提供されているパッケージのリストがあります。
compiz ekiga evolution evolution-connector evolution-webcal fribidi gaim gnome-games gnome-pilot gnome-pilot-conduits gnome-spell gnome-user-share hsqldb jpilot k3b kdeaddons kdegames kdegraphics kdemultimedia kdepim launchmail libgpod libsilc libwpd nautilus-sendto opal openoffice.org perl-Archive-Zip pilot-link planner pwlib python-imaging redhat-release-5Client redhat-release-notes-5Client-5 rhythmbox scribus taskjuggler thunderbird
Server でのみ提供されているパッケージです。
Cluster_Administration clustermon compat-gcc-295 conga elilo gfs-kmod gfs-kmod gfs-utils Global_File_System gnbd gnbd-kmod gnbd-kmod iprutils ipvsadm libica librtas libunwind lvm2-cluster openssl-ibmca piranha ppc64-utils prctl redhat-release-5Server redhat-release-notes-5Server-5 rgmanager s390utils salinfo system-config-cluster yaboot
私は、ちょうど自分で追加したパッケージが他のパッケージを要求するように変更され、そのパッケージをビルドする必要があります。どうやってこれを行えば良いですか？
あなたは rel-eng Trac で buildroot を上書きするように要求する必要があるでしょう。これは新たにビルドされたパッケージに対してビルドを許可するようにします。https://fedorahosted.org/rel-eng/newticket でチケットを登録することができます。ビルドしたパッケージを今後は必要としなくなったとき、又はあなたのパッケージが安定板リポジトリへ追加されるときに、ビルドしたパッケージを削除するように再度、上書きを要求すべきです。安定板リポジトリのパッケージは自動的に buildroot へ追加されます。
どのパッケージが EPEL に存在するかはどうやって分かりますか？
RHEL の browse the SRPMs や CentOS のようなリビルドされたツリーを確認してください。EPEL は RHEL の拡張プラットホームで提供されているパッケージは提供しません。基本的には RHEL5 のサーバ/ワークステーション向けと RHEL4 のベースになります。これらのパッケージは RHEL4 と RHEL5-Client と RHEL5-Server にあります。
私は EPEL 向けのパッケージをビルドしたいですが、そのパッケージと依存性があるパッケージは EPEL でまだ利用可能になっていません。又は EPEL でまだ利用可能ではない Fedora のパッケージを知りたいです。
EPEL に存在する Fedora パッケージの取得方法を参照してください。
EPEL4 向けのベースとして旧バージョンか新バージョンのどちらを採用すべきですか？
Fedora Core からのパッケージと Extras3 は EPEL4 向けのベースとして始まりました。Fedora Extras3 からのパッケージは RHEL4 向けにリビルドされたもので、centos.karan.org にある外部リポジトリによって提供されました。大雑把にテストされて、おそらくは動くだろうというところから始めて優れたベースとなりました。EPEL4 のパッケージをビルドする前にそこにある追加の変更内容を探すようにしてください。どのようなアイディアや変更であっても共有するためにリポジトリメンテナへ相談することをお奨めします。
その他
あるパッケージを EPEL から取得できるようにしたいです。どうすれば良いですか？
そのパッケージを Fedora へ追加して、しばらくユーザにテストしてもらってください。テストが完了したら、EPEL へプッシュすることができます。言い換えると、パッケージを作成する、Bugzilla を通してレビュー用にパッケージを提案する、レビューと認可を得る、Fedora へ追加するといった順番に作業を進めます。その後、EPEL ブランチをリクエストします。
あるパッケージを Fedora へ追加せずに EPEL からのみを取得するのは可能ですか？
シンプルに Fedora 向けのレビュープロセスを通して、初期追加のための RHEL のみを対象としてください。しかし、Fedora でパッケージがメンテナンスされることは、あなたにとって多くのメリットがあることに注意してください。Fedora と EPEL の両方でパッケージをメンテナンスすることを検討すべきです。
EPEL から削除されたパッケージを取得するのはどうすれば良いですか？
我々は普通はリリースしたパッケージを削除することはしません。しかし、例えば、EPEL-testing で何かのパッケージをビルドしていて、重要な依存関係がなくなっていることに気付いたら、我々が削除した可能性があります。epel_signers-members AT fedoraproject DOT org へ連絡してください。
EPEL の通常プロセスの更新パッケージをすぐに取得する必要があるときはどうすれば良いですか？
セキュリティアップデートや重大なバグ修正でない限り、安定版リポジトリへ直接的にパッケージを追加しようとしないでください。更新されたパッケージを安定版リポジトリへ追加するクライテリアがないならば、あなたのリクエストを testing リポジトリへ変更する epel rel-eng/signers によって強制されます
通常の更新は、安定版リポジトリへ追加される前に testing リポジトリで少なくとも2週間は寝かせなければなりません。2週間後、安定版リポジトリへのリクエストを出すか、追加する前に菩提へ至るカルマを体得するまでその更新を待つかをあなたが決定します。
ゲームや同種のパッケージは厳密にはエンタープライズユーザを対象としていないですよね？
はい。エンタープライズディストリビューションを自宅のデスクトップ等で使用する人々がいます。というのは Fedora のリリースや更新サイクルは彼らの要求しているものよりも速いからです。そのような人々の何人かはゲームや他のエンタープライズではないソフトウェアも使用したいです。そのようなパッケージをリポジトリに追加しておいても、別のニーズでエンタープライズディストリビューションを使用する人へ何の影響も与えません。
RHEL が提供していない全ての Fedora パッケージを単純にビルドしないのはどうしてですか？
我々は長期間、パッケージのメンテナンスに所有権とコミット権を持ってくれるメンテナを必要としています。ただ単純に全てのパッケージを自動的にリビルドすることはパッケージを壊してしまう確率が高いです。
ここに質問が見当たらない？
EPEL チームへ連絡してください。