「EPELは、Fedora内部から参加しているパッケージメンテナのコミュニティである。多くの人々は、Fedora版のメンテナンスも兼任している」とFedora Docs Projectの主力メンバーKarsten Wade氏は先週金曜のfedora-announce-listで説明している。このリポジトリには約1000パッケージが含まれており、今のところその数は「毎週数十パッケージずつ」増えているとWade氏は話す。
EPELのインフラストラクチャは提供しているものの、Red Hatはこのリポジトリの商用サポートは行っていない。EPEL/FAQによると、EPELリポジトリはFedoraと同様に「ボランティアベースの活動」と位置付けられ、Red Hatの技術者がメンテナやプロジェクトリーダとして関与している。先ほどのFAQでは、EPELが他のサードパーティリポジトリと大きく違うのは以下の点だと説明されている。
- 「Fedora Packagingガイドラインの遵守」により、タイトな統合が保証される。
- RHELコンポーネントの置き換えではない「無償のアドオン」パッケージだけを提供する。
- 貢献者やメンテナの大型コミュニティが存在し、そこにはボランティアだけでなくRed Hatの技術者も参加している。
- 「特許や法的問題に煩わされることのない純粋なFLOSS（Free/Libre Open Source Software）」だけを提供する。
さらに、リポジトリ内のパッケージをRHELだけでなくCentOSやScientific Linuxなど他のFedora派生ディストリビューションでも確実に動作させることが「プロジェクトの明確なゴール」になっている。
またFAQによると、以下のように、他のサードパーティリポジトリとの互換性が問題になる可能性があるという。
EPELは、RHELおよびRHEL互換の派生ディストリビューション向けのアドオンリポジトリとして作られています。同じシステム上で競合する他のサードパーティリポジトリとEPELを混同させないことが、問題を回避する最善の方法です。しかし、なかにはそうしたことをしてしまってyum prioritiesプラグインのおかげで最悪の事態を免れる人もいるでしょう。
EPELのパッケージに別のリポジトリとの互換性がない、あるいは、依存関係の解決途中にyumやup2dateによって危機を脱したという問題に遭遇した場合は、Bugzillaにバグレポートを提出し、もう一方のリポジトリのメンテナにも連絡を取ってください。
EPELパッケージはマスターミラーとその他いくつかのサイトから入手できる。こちらのリストをスクロールさせながら参照すれば最寄りのサイトが見つかるはずだ。
EPELから取得したソフトウェアをインストールするために、同リポジトリにはRHEL4およびRHEL5用のRPM Package Managerが用意されている。
RHELまたはその派生版の1つを使用していて「パッケージのメンテナンスに必要なスキルを身に付けているか習得する気がある」人であれば、自由にEPELリポジトリに貢献できる、とFAQには記されている。なお、FAQには、貢献者やメンテナを志望する人向けの詳細な情報も掲載されている。また、万人向けの詳しい情報は、EPELのWikiで参照できる。
ちなみに、自宅のコンピュータで企業向けLinuxを使っている人なら、このEPELリポジトリにゲームをはじめとする「企業向けでないソフトウェア」も含まれているかどうかに興味があるかもしれ ない。
Shirl Kennedyは、ブログ「DocuTicker」および「ResourceShelf」のシニアエディタ。Information Today紙にも「Internet Waves」というコラムを寄稿。1982年からテクノロジに関する執筆で活躍している。