From Fedora Project Wiki

< EPEL‎ | FAQ
m (epel-release パッケージのバージョンアップデート)
 
(47 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{autolang}}
== EPEL とは何？ ==
== EPEL とは何？ ==


Line 5: Line 7:
Fedora パッケージングコミュニティの一部として、EPEL パッケージは 100% フリーなオープンソースソフトウェアです(FLOSS)。
Fedora パッケージングコミュニティの一部として、EPEL パッケージは 100% フリーなオープンソースソフトウェアです(FLOSS)。


== Fedora Project はどうして EPEL のスポンサーをしてるの？ ==
== Fedora プロジェクトはどうして EPEL のスポンサーをしてるの？ ==


多くの Fedora やエンタープライズ Linux の貢献者たちとユーザが EPEL パッケージを提供するために Fedora プロジェクトで作業したいと考えています。
多くの Fedora やエンタープライズ Linux の貢献者たちとユーザが EPEL パッケージを提供するために Fedora プロジェクトで作業したいと考えています。
Line 17: Line 19:
== EPEL プロジェクトが提供するパッケージは RHEL や互換ディストリビューションのどのリリース向けですか？ ==
== EPEL プロジェクトが提供するパッケージは RHEL や互換ディストリビューションのどのリリース向けですか？ ==


EPEL プロジェクトは RHEL 5.x と 4.x リリースと互換ディストリビューションのアドオンパッケージを提供します。RHEL 3 や 2.1 向けのパッケージは、[http://www.redhat.com/security/updates/errata/ errata support policy] によると、メンテナンスフェーズになるので提供されていません。Fedora をベースとするパッケージは、適切にメンテナンスするのが難しい RHEL 3 や 2.1 のリリースで利用できる古いバージョンのパッケージをビルドしないでしょう。
EPEL プロジェクトは RHEL 5.x と 4.x リリースと互換ディストリビューション(例えば [http://www.centos.org CentOS])のアドオンパッケージを提供します。RHEL 3 や 2.1 向けのパッケージは、[http://www.redhat.com/security/updates/errata/ errata support policy] によると、メンテナンスフェーズになるので提供されていません。Fedora をベースとするパッケージは、適切にメンテナンスするのが難しい RHEL 3 や 2.1 のリリースで利用できる古いバージョンのパッケージをビルドしないでしょう。
 
== EPEL は RHEL や互換ディストリビューション向けの他のサードパーティリポジトリとどう違いますか？ ==
 
* ほとんどの EPEL パッケージは Fedora リポジトリの同等パッケージから派生したものか、ビルドされたパッケージで、同じ人によってメンテナンスされています。エンドユーザからのフィードバックやテスト、仲間のレビューを通じて改良もされています。
* EPEL に付属するよく知られたドキュメントは[[Packaging/Guidelines|  Fedora パッケージングガイドライン]]は、RHEL が始めたものです。これは優れたインテグレーションであることを保証します。
* EPEL は純粋にフリーなアドオンリポジトリですが、RHEL や階層プロダクトのパッケージを置き換えるものではありません。
* EPEL はリポジトリをメンテナンスする Red Hat エンジニアと有志のコミュニティメンバーを含む大きな貢献者のチームがあります。
* EPEL は特許や法的問題がないフリーでオープンソースソフトウェアのみを提供します。


== How is EPEL different from other third party repositories for RHEL and derivatives? ==
その他のリポジトリについて [http://wiki.centos.org/AdditionalResources/Repositories CentOS FAQ] も参照してください。


* EPEL packages are in most cases built or derived from the equivalent ones in Fedora repository and maintained by the same people. It has also been improved through peer reviews, testing and feedback from end users.
== EPEL パッケージは RHEL や互換ディストリビューションのみで利用可能なものですか？ ==
* EPEL adheres to the well documented [[Packaging/Guidelines|  Fedora Packaging guidelines]] , which RHEL has started following. This ensures good integration.
* EPEL is purely a complimentary add-on repository and does not replace packages in RHEL or layered products.
* EPEL has a large team of contributors including Red Hat engineers and volunteer community members working together to maintain the repository.
* EPEL only provides free and open source software unencumbered by patents or any legal issues.


== Are EPEL packages available only for RHEL or also for compatible derivatives? ==
パッケージは自由に利用可能です。'''プロジェクトの明確な目的は CentOS や Scientific Linux のような RHEL ベースのディストリジューションで利用できるようにすることです。'''


Packages are freely available and it is an '''explicit goal of the project to make sure they are usable for RHEL-based distributions such as CentOS and Scientific Linux.'''
== EPEL は RHEL や階層プロダクトが提供しているパッケージを置き換えるものですか？ ==


== Does EPEL replace packages provided within Red Hat Enterprise Linux or layered products? ==
いいえ、違います。EPEL はアドオンパッケージを提供するための純粋にフリーなリポジトリです。


No. EPEL is purely a complimentary repository that provide add-on packages.
== EPEL に存在するパッケージの更新に関するポリシーはどのようなものですか？ ==


== What is the policy on updates for packages in EPEL? ==
詳細は [[EPEL/GuidelinesAndPolicies| EPEL パッケージのメンテナンスと更新]]ポリシーを参照してください。


Refer to the [[EPEL/GuidelinesAndPolicies| EPEL package maintenance and updates]]  policy for all the details.
== Fedora プロジェクトは EPEL パッケージの品質をどのように保証しますか？ ==


== How does Fedora Project ensure the quality of the packages in EPEL? ==


Packages are peer reviewed against extensive packaging guidelines before being imported into the repository. Only updates that fix important bugs get pushed to the stable repository directly. Other updates hit a testing repository first and get released as an EPEL scheduled update in parallel with the EL scheduled updates. Packages often are tested in Fedora, too. The Fedora Packaging Guidelines and QA team back up all these efforts, helping to avoid errors. There are also discussions for more strict QA policies. Do participate and help us.
リポジトリへパッケージが追加される前に広範囲なパッケージングガイドラインの項目を満たしているかを仲間内でレビューします。唯一、重要なバグ修正の更新だけは直接的に安定板のリポジトリへ追加されます。その他の更新はエンタープライズ Linux の更新スケジュールと並行して、先ずテスト用のリポジトリへ置かれ、その後 EPEL の予定されたスケジュールに沿ってリリースされます。パッケージは Fedora でもよくテストされます。Fedora パッケージングガイドラインと QA チームは、このような全ての作業を支援して、エラーが発生しないように手伝ってくれます。また、さらに厳しい QA ポリシーのための議論も行います。どうか我々に加わって、協力してください。


== How long are EPEL packages updated? ==
== EPEL パッケージはどのぐらいの期間に対して更新されていますか？ ==


The plan is for EPEL packages to get updates as long as the corresponding RHEL release is supported. That is seven years after the initial release according to the current [http://www.redhat.com/security/updates/errata/ errata support policy] .
EPEL パッケージの更新は RHEL のリリースがサポートされている期間に対応するよう計画されています。現在の [http://www.redhat.com/security/updates/errata/ errata support policy] によると、初期リリース後、7年間になります。


== How can we be sure that someone will maintain the packages until end of life of the distribution the packages were built for? ==
== あるディストリビューション向けにビルドされたパッケージをそのディストリビューションのEOL(エンドオブライフ)までに誰かがパッケージをメンテナンスしてくれることを保証できますか？ ==


The only way to be sure is to do it yourself, which is coincidentally the reason EPEL was started in the first place.
唯一の確実な方法は、あなたがメンテナンスを行うことです。そもそも EPEL が始まった理由は偶然にもそういった経緯からです。


Software packages in EPEL are maintained on a voluntary basis. If you to want ensure that the packages you want remain available, get involved directly in the EPEL effort. More experienced maintainers help review your packages and you learn about packaging.  If you can, get your packaging role included as part of your job description; EPEL has written a [[EPEL/PackageMaintainer/GenericJobDescription| generic description]] that you can use as the basis for adding to a job description.
EPEL に存在するパッケージは基本的に有志でメンテナンスされています。パッケージが継続的に利用可能である状態をあなたが望むなら、直接、EPEL プロジェクトに参加してメンテナンスを行ってください。経験豊富なメンテナがあなたのパッケージのレビューを手伝ってくれるでしょう。そして、あなたはパッケージングについて学ぶことができます。あなたがそれをできるなら、職務欄の一部にパッケージング業務を書くことができます。職務欄へ追加するための基本事項は[[EPEL/PackageMaintainer/GenericJobDescription| 一般的な作業内容]]に記載されている内容です。


We do our best to make this a healthy project with many contributors who take care of the packages in the repository, and the repository as a whole, for all releases until RHEL closes support for the distribution version the packages were built for.  That is seven years after release (currently) -- a long time frame, and we know a lot can happen in seven years. Your participation is vital for the success of this project.
リポジトリにあるパッケージのメンテナンスをしてくれる多くの貢献者と共にこの健全なプロジェクトにすることに全力を尽くしてきました。そして、作成されたリポジトリは全体として、RHEL がそのディストリビューションのバージョンのサポートを中止するまで続けられます。これは(現在では)7年間になります。7年間もの長期間に渡ると、色んな出来事が起こるでしょう。このプロジェクトの成功には、あなたの参加が不可欠です。


== What if my ISV/IHV wants to maintain a package in EPEL? ==
== 私の所属する ISV/IHV が EPEL にあるパッケージのメンテナンスを望む場合はどうなりますか？ ==


Software and hardware vendors are encouraged to get involved in EPEL.  For more information, read the [[About EPEL#ISV.2FIHV_Perspective| ISV/IHV Perspective]].
ソフトウェアやハードウェアベンダは EPEL に参加することが推奨されます。詳細は[[About EPEL/Japanese#ISV.2FIHV_Perspective| ISV/IHV からの視点]]を参照してください。


= EPEL を利用する =
= EPEL を利用する =
Line 68: Line 73:
リポジトリパッケージは <code>yum</code> や <code>up2date</code> を使用するための repo ファイルをインストールします。その後、EPEL リポジトリも含めて、通常の方法でパッケージをインストールすることができます。
リポジトリパッケージは <code>yum</code> や <code>up2date</code> を使用するための repo ファイルをインストールします。その後、EPEL リポジトリも含めて、通常の方法でパッケージをインストールすることができます。


<pre>su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm'
<pre>su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm'
...
...
su -c 'yum install foo'
su -c 'yum install foo'
Line 91: Line 96:
== EPEL は (Fedora Extras であったのような) の"アップストリーム" や "公式パッケージリポジトリ"  ですか？ ==
== EPEL は (Fedora Extras であったのような) の"アップストリーム" や "公式パッケージリポジトリ"  ですか？ ==


EPEL is just one of several add on repositories with RPM packages for RHEL and derivates. It is not an official repository. The different repositories serve different user bases or follow different ideas.
EPEL は RHEL や互換ディストリビューションの RPM パッケージの幾つかあるアドオンリポジトリの1つです。EPEL は公式リポジトリではありません。そういった違うリポジトリは違う目的やユーザベースを担います。


Just like RHEL itself, EPEL in reality is more a "downstream" in the sense that Fedora is upstream and EPEL, just like Red Hat, takes packages for its product that are constantly developed, tested and receive feedback in Fedora. Red Hat, through their sponsorship for the Fedora project and participation of Red Hat maintainers, continues to back EPEL, but Red Hat has not endorsed EPEL or commercially supported it.
ちょうど RHEL 自身のような、実際の EPEL は Fedora がアップストリームであれば "ダウンストリーム" になります。EPEL は RHEL と同様、Fedora で常に開発、テスト、フィードバックを受けているパッケージを自身のプロダクトに取り込みます。Red Hat は Fedora プロジェクトへの資金援助や Red Hat メンテナの参加を通じて EPEL にも還元しますが、Red Hat が EPEL を保証したり、商用サポートすることはありません。


The EPEL maintainers are well aware that EPEL can't serve all needs, and that other repositories are likely needed, for types of software the Fedora project won't provide, which currently includes packages for EPEL with a rolling release model or non-free and patent encumbered software.
EPEL メンテナは EPEL が全てのニーズを満たすことができないということをよく分かっています。そのため、他のリポジトリが Fedora プロジェクトでは提供しないソフトウェアのために必要とされています。他のリポジトリでは、現在、ローリングリリースモデルによる EPEL 向けのパッケージか、フリーではない特許が関連するソフトウェアを提供します。


== EPEL は repotags を利用しないのですか？ ==
== EPEL は repotags を利用しないのですか？ ==


There were a lot of long discussions in the months of EPEL about using repotags or not. Lots of people from inside and outside of Fedora and EPEL, as well as maintainers from other repositories, participated in those discussions. No real agreement could be found as to whether the benefits outweigh the disadvantages - part of the problem was that people sometimes couldn't agree on the benefits or disadvantages repotags have (or if there are any). The final decision in three voting sessions (one done by FESCo before EPEL had a Steering Committee and twice done by EPEL's first Steering Committee) was to go without repotags in EPEL.
EPEL の初期に repotags を利用するかどうかについて、長時間の議論がありました。Fedora と EPEL の内外の多くのメンバーが、他のリポジトリのメンテナ同様、その議論に参加しました。その恩恵が不便な点を上回るような、本当の意味での同意が誰にも得られませんでした。その問題の一部には repotags が持っている(又はそれ以外)恩恵や不便な点について、議論に参加したメンバー同士で意見が一致しないことがあったからです。最終的に3回の投票(1回目は EPEL 運営委員会が発足する前の FESCo によるもの、後の２回は EPEL 運営委員会)を行って EPEL では repotags を利用しないことに決定しました。


== あるパッケージが EPEL リポジトリのパッケージなら、どうやって分かりますか？ ==
== あるパッケージが EPEL リポジトリのパッケージなら、どうやって分かりますか？ ==


If you want to find out if a package comes from EPEL, use a query such as this:
EPEL 由来のパッケージであるかどうかを調べるには、次のようなクエリを実行してください:


<pre>
<pre>
Line 114: Line 119:
</pre>
</pre>


Or you can install and run the 'keychecker' script to list all packages signed with a particular key as well as which repo they came from.
あるいは、提供されたリポジトリの公開鍵で署名された全パッケージをリスト化する 'keychecker' スクリプトをインストールして実行することもできます。


== EPEL は他のサードパーティリポジトリと協調しようとしますか？ ==
== EPEL は他のサードパーティリポジトリと協調しようとしますか？ ==


EPEL is always willing to discuss cooperation with other parties and repositories and encourages maintainers to do so whenever possible.
EPEL はいつも他のチームやリポジトリと協調しようと議論していて、可能な限りそうするようにメンテナへ推奨しています。


== 他のサードパーティリポジトリとの互換性についてはどうですか？ ==
== 他のサードパーティリポジトリとの互換性についてはどうですか？ ==


Mixing different RPM repositories that were not designed to be mixed can lead to incompatibilities that often result in dependency resolution problems in yum or up2date. Sometimes it even happens that software is not working as expected if libraries and applications come from different repositories. EPEL is designed as an add-on repository for RHEL and compatible derivatives. The best way to avoid problems is to avoid mixing EPEL with other third party repositories that have conflicting packages on the same system. Some people nevertheless do it and the yum priorities plugin can help to avoid the worst problems.
もともと混在させるように設計されていない別々の RPM リポジトリを混在させると、yum や up2date による依存解決の問題を発生させる非互換な状態を招きます。ライブラリやアプリケーションが違うリポジトリから取得した場合、期待したように動作しないソフトウェアも時々あります。EPEL は RHEL や互換ディストリビューションへのアドオンリポジトリとして設計されています。問題を避けるための最善の方法は、同じシステム上で競合するパッケージを持つサードパーティリポジトリを EPEL と混在させないことです。そうは言っても、人によっては混在させたい場合もあるので、yum priorities プラグインが最悪の問題を避けるために役立つでしょう。


If you encounter a problem where packages from EPEL are incompatible with another repository, or lead yum or up2date to bail out during dependency resolution, please report a bug to [http://bugzilla.redhat.com Bugzilla] and contact the maintainer of the other repositories. The EPEL project encourages its maintainers to solve such problems together with the maintainers from other repositories in order to find a solution that is acceptable for both sides. However, there is no guarantee such a solution can or will be found in every case, as technical solutions to solve a repository-mixing issue might have side-effects or drawbacks for one of the repositories involved.
EPEL のパッケージが他のリポジトリと非互換、又は yum や up2date が依存解決中に失敗する問題に遭遇したなら、[http://bugzilla.redhat.com Bugzilla] にバグ登録して、他のリポジトリのメンテナへも連絡を取るようにしてください。EPEL プロジェクトは問題解決のために自身のメンテナと他のリポジトリのメンテナと一緒になって、双方の側で受け入れられる解決策を探そうとします。しかしながら、そのような解決策がいつも見つかるという保証はありません。リポジトリ混在問題の技術的な解決策は、リポジトリの一方に障害や副作用をもたらすかもしれないからです。


= Contributing to EPEL =
= EPEL への貢献 =


== General ==
== 全般 ==


== Who can contribute to EPEL? ==
== どんな人が EPEL に貢献できるの？ ==


Anyone may contribute to EPEL. If you are using RHEL or compatible spin off's, and you have the required skills for maintaining packages or are willing to learn, you are welcome to contribute.
誰もが EPEL に貢献できるでしょう。あなたが RHEL や互換ディストリビューションを使用していて、パッケージメンテナンスのスキルを持っているか自らそれらを学ぶ意欲があるなら、いつでもプロジェクトに参加してください。


== Questions specific to existing Fedora contributors ==
== Fedora プロジェクトで既に活動している貢献者向けへの質問 ==


=== How do I get my packages into EPEL? ===
=== EPEL へパッケージを追加するにはどうすれば良いですか？ ===


You have to follow the same [[PackageMaintainers/Join|  process]]  as Fedora except that you can request an EPEL branch, tag, and build.
EPEL ブランチ(EL4, EL5, EL6 等)、タグ、ビルドにリクエストできるパッケージ以外は Fedora と同じ[https://fedoraproject.org/wiki/Join_the_package_collection_maintainers/ja プロセス]に従う必要があります。


=== How do I request a EPEL branch for an existing Fedora package? ===
=== 既存の Fedora パッケージのために EPEL ブランチをどうやってリクエストすれば良いですか？ ===


Please follow the usual Fedora method with a [http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#other Package Change Request] .
[https://fedoraproject.org/wiki/Package_SCM_admin_requests/ja#.E6.97.A2.E5.AD.98.E3.83.91.E3.83.83.E3.82.B1.E3.83.BC.E3.82.B8.E3.81.AE.E3.83.91.E3.83.83.E3.82.B1.E3.83.BC.E3.82.B8.E5.A4.89.E6.9B.B4.E3.83.AA.E3.82.AF.E3.82.A8.E3.82.B9.E3.83.88 パッケージ変更リクエスト] で説明されている Fedora の通常方法に従ってください。あなたは自分のパッケージのバグレビューを使用することができます。あるいは、もしバグレビューを見つけられなかったら、そのパッケージのバグ登録を行って CVS リクエストのためにバグレビューを利用してください。あなたは Fedora メンテナでもあることを忘れないように注意してください。
You can use the bug review for your package, or if you cannot find the bug review, you can open a new bug on the package and use that for your CVS request. Make sure and note that you are the Fedora maintainer.


=== I maintain a package in Fedora. Do I have to maintain it for EPEL now, too? ===
=== 私は Fedora でパッケージをメンテナンスしています。EPEL でも同様にメンテナンスしなければならないのですか？ ===


No. You can if you want, or you can ask someone else to maintain the package in EPEL for you. In some cases, you may be approached by a current EPEL maintainer who wants to maintain your package in EPEL.
いいえ。あなたがメンテナンスしたいならやってください。あるいは誰かに EPEL のパッケージのメンテナンスを依頼することもできます。時には EPEL であなたのパッケージをメンテナンスしたい EPEL のメンテナから連絡があるかもしれません。


=== I maintain a package in Fedora and want to maintain packages in EPEL, too, but I don't have a RHEL subscription for testing?  ===
=== 私は Fedora でパッケージをメンテナンスしていて、EPEL でも同様にメンテナンスをしたいです。しかし、テストをするための RHEL サブスクリプションがありません ===


You can use a compatible derivative of RHEL for testing, it should be 100% compatible. Mock is available in Fedora and ships config files that can be used to test build the packages.
テストをするために RHEL の互換ディストリビューションを利用することできます。それは 100% 互換性があります。Fedora では Mock が利用可能で、パッケージをテストビルドするために使用される config ファイルが提供されています。


=== I'm a Fedora contributor and want to maintain my packages in EPEL, too. What do I have to do and what do you expect from me?  ===
=== 私は Fedora の貢献者で EPEL でも同様にメンテナンスをしたいです。私は何をしなければならなくて、EPEL プロジェクトは私に何を期待していますか？ ===


All Fedora packagers can request EPEL branches in CVS via the normal procedure. Please keep in mind that by building your packages in EPEL we expect that you are aware of the [[EPEL/GuidelinesAndPolicies| special EPEL guidelines and policies]] and that you will adhere to them. You should also plan to maintain the packages for the near future -- ideally for several years, or for the full planned lifetime of EPEL.  Remember that RHEL has a planned lifetime of seven years.
全ての Fedora パッケージャは通常方法で CVS に EPEL ブランチをリクエストすることができます。自分のパッケージを EPEL でビルドするにあたって[[EPEL/GuidelinesAndPolicies/ja| EPEL に特化したガイドラインとポリシー]]を承諾していると見なすので注意してください。また、EPEL のライフサイクル期間や数年間に及ぶ今後のパッケージメンテナンス計画を立てるべきです。RHEL のライフサイクルは7年間を予定していることを覚えておいてください。


You may want to look into formalizing your packaging role in your company or other organization.  If you can do that, this [[EPEL/PackageMaintainer/GenericJobDescription| generic job description]] may help.  Aside from making sure that you are recognized for the value you give your organization, formal role recognition ensures that your organization has someone continuing to maintain the package, even if someone new is in the role.
あなたは自分の会社や組織で行うパッケージングの役割を正式なお仕事にしたいと考えるかもしれません。もし、そうできるなら、[[EPEL/PackageMaintainer/GenericJobDescription/ja| 一般的な作業内容]]が役に立つでしょう。自分の組織にパッケージング作業は価値があると認識されます。さらに新しい人がその役割になったとしても、組織内で継続的にパッケージをメンテナンスする人が必要であることが確認されます。


For testing the packages before and after building please use RHEL if you have a subscription, or the freely available RHEL-based distros such as CentOS or Scientific Linux.
ビルド作業の前後におけるパッケージテストのために RHEL のサブスクリプション登録があるなら RHEL を、又は CentOS や Scientific Linux のようなフリーな互換ディストリビューションを利用してください。


=== How do you make sure that packages in EPEL and in Fedora do not split? ===
=== EPEL と Fedora に存在するパッケージを分割しないようにするにはどうすれば良いですか？ ===


The plan is to have one primary maintainer per package who is responsible for making certain that the package enhancements applied to one tree (for example, EL4) find their way into the other trees (for example, Fedora devel).
1つのツリー(例えば、RHEL4)に適用されるパッケージの機能拡張が他のツリー(例えば、Fedora devel)へ追加されるように確認することに責任を持つ主メンテナを持つ計画があります。


This maintainer decides what makes sense to apply for the package in general. New EL branches for new EL releases are normally created from the associated Fedora branch on which the EL release is based. Therefore, the EL maintainer has a genuine interest in getting enhancements merged into Fedora.
このメンテナがどのような拡張方法が普通に理解出来るかを決定します。新たなリリース向けの RHEL ブランチは普通は RHEL リリースのベースにするための Fedora ブランチから作成されます。そのため、RHEL メンテナは Fedora にマージされた機能拡張を後で取り込むことに対して真面目に取り組んでいます。


=== Will my packages from Fedora simply build unchanged on EPEL5 ===
=== Fedora から持ってきた私のパッケージは RHEL5 で何も変更せずシンプルにビルドしても良いですか？ ===


Most likely they will build unchanged. However, there are specific items to consider. All your build requirements in the package must be part of RHEL5 or EPEL5.
多くのパッケージは何も変更せずにビルドできるでしょう。しかしながら、注意が必要なパッケージもあります。全てのビルドに必要な依存パッケージは RHEL5 か EPEL5 に含まれる必要があります。


You can maintain these packages in EPEL yourself if it was reviewed and the main Fedora packager is not interested in maintaining them for EPEL. Just request a branch for EPEL with you as the per-repo maintainer. Be sure to inform the Fedora packager.
もし EPEL のメンテナンスに興味がない Fedora の主パッケージャにレビュー済みのものであれば、あなたがこれらのパッケージをメンテナンスすることができます。あなたが per-repo メンテナとして EPEL 用のブランチをリクエストしてください。必ず Fedora パッケージャへ連絡するようにしてください。


There are also some packages that are only part of RHEL Server, while others are only part of RHEL Desktop. Since RHEL-ppc is only available as Server you can't use the packages that are only part of the client as BuildRequires. In that case, you will probably need to add arch specific conditionals to your spec file.
また、RHEL Server では提供されていなくて、RHEL Desktop でのみ提供されているパッケージも幾つかあります。RHEL-ppc は Server しか提供されていないので BuildRequires として Desktop のみのパッケージを利用することができません。そのような場合、spec ファイルにアーキテクチャ独自の条件を追加する必要があるでしょう。


Here is a list of packages that are only part of the client:
ここに Desktop でのみ提供されているパッケージのリストがあります。
<pre>
<pre>
compiz
compiz
Line 217: Line 221:
</pre>
</pre>


These are only part of the server:
Server でのみ提供されているパッケージです。


<pre>
<pre>
Line 251: Line 255:
</pre>
</pre>


=== I need to build a package that in turn requires another one I have just added. How do I do this? ===
=== 私は、ちょうど自分で追加したパッケージが他のパッケージを要求するように変更され、そのパッケージをビルドする必要があります。どうやってこれを行えば良いですか？ ===


You will need to request a buildroot override in the rel-eng trac instance. This will allow you to build against the other newly built package. You can file a ticket at: [https://fedorahosted.org/rel-eng/newticket https://fedorahosted.org/rel-eng/newticket]. You should do your build and then request the override be removed when you no longer need it or when your package reaches the stable repository. Packages in the stable repository are automatically added to the build root.
あなたは rel-eng Trac で buildroot を上書きするように要求する必要があるでしょう。これは新たにビルドされたパッケージに対してビルドを許可するようにします。[https://fedorahosted.org/rel-eng/newticket https://fedorahosted.org/rel-eng/newticket] でチケットを登録することができます。ビルドしたパッケージを今後は必要としなくなったとき、又はあなたのパッケージが安定板リポジトリへ追加されるときに、ビルドしたパッケージを削除するように再度、上書きを要求すべきです。安定板リポジトリのパッケージは自動的に buildroot へ追加されます。


=== How can I know which packages are part of RHEL? ===
=== どのパッケージが EPEL に存在するかはどうやって分かりますか？ ===


Look at the rebuilds trees such as CentOS, or
RHEL の [ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ browse the SRPMs] や CentOS のようなリビルドされたツリーを確認してください。EPEL は RHEL の拡張プラットホームで提供されているパッケージは提供しません。基本的には RHEL5 のサーバ/ワークステーション向けと RHEL4 のベースになります。これらのパッケージは [ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os RHEL4] と [ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Client RHEL5-Client] と [ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server RHEL5-Server] にあります。
[ftp://ftp.redhat.com/pub/redhat/linux/enterprise/ browse the SRPMs]  
for RHEL. EPEL will not ship a package that is in the RHEL Advanced platform set. This is basically anything in the server or workstation for RHEL5, and anything in base RHEL4. This would be: [ftp.redhat.com:/pub/redhat/linux/enterprise/4/en/os RHEL4] and [ftp.redhat.com:/pub/redhat/linux/enterprise/5Client RHEL5-Client] and [ftp.redhat.com:/pub/redhat/linux/enterprise/5Server RHEL5-Server]


=== I want to build packages for EPEL but some of my packages dependencies are not available in EPEL -- or -- I'd like to see a Fedora package in EPEL that is not yet available there ===
=== 私は EPEL 向けのパッケージをビルドしたいですが、そのパッケージと依存性があるパッケージは EPEL でまだ利用可能になっていません。又は EPEL でまだ利用可能ではない Fedora のパッケージを知りたいです。 ===


See [[Getting_a_Fedora_package_in_EPEL| here how to get a Fedora package in EPEL]].
[[Getting_a_Fedora_package_in_EPEL| EPEL に存在する Fedora パッケージの取得方法]]を参照してください。


=== Should I take old or latest software as a base for EPEL4? ===
=== EPEL4 向けのベースとして旧バージョンか新バージョンのどちらを採用すべきですか？ ===


The packages from Fedora Core and Extras 3 are a good starting base for EPEL 4. The packages from Fedora Extras 3 were rebuilt for EL4 and shipped by a external repository at  [http://centos.karan.org/ centos.karan.org] . They are a good base to start from as it is already tested in the wild and will likely work. Consider looking there for additional fixes before building your package for EPEL4. It is recommended that you coordinate with the repository maintainers to share any ideas and fixes.
Fedora Core からのパッケージと Extras3 は EPEL4 向けのベースとして始まりました。Fedora Extras3 からのパッケージは RHEL4 向けにリビルドされたもので、[http://centos.karan.org/ centos.karan.org] にある外部リポジトリによって提供されました。大雑把にテストされて、おそらくは動くだろうというところから始めて優れたベースとなりました。EPEL4 のパッケージをビルドする前にそこにある追加の変更内容を探すようにしてください。どのようなアイディアや変更であっても共有するためにリポジトリメンテナへ相談することをお奨めします。


== Miscellaneous ==
== その他 ==


=== I want to get a package into EPEL. What do I have to do? ===
=== あるパッケージを EPEL から取得できるようにしたいです。どうすれば良いですか？ ===


Get it into Fedora and tested by users for a while. Once it has been tested, it can be pushed to EPEL. In other words: create a package, propose the package for review via bugzilla, get it reviewed and approved, and import it into Fedora. After that, request an EPEL branch for your package.
そのパッケージを Fedora へ追加して、しばらくユーザにテストしてもらってください。テストが完了したら、EPEL へプッシュすることができます。言い換えると、パッケージを作成する、Bugzilla を通してレビュー用にパッケージを提案する、レビューと認可を得る、Fedora へ追加するといった順番に作業を進めます。その後、EPEL ブランチをリクエストします。


=== Is it possible to get a package only into EPEL and not Fedora? ===
=== あるパッケージを Fedora へ追加せずに EPEL からのみを取得するのは可能ですか？ ===


Simply go through the review process for Fedora and specify only EL targets for the initial import. But note that maintaining packages in Fedora has many advantages for you, you should consider maintaining the package in both Fedora and EPEL.
シンプルに Fedora 向けのレビュープロセスを通して、初期追加のための RHEL のみを対象としてください。しかし、Fedora でパッケージがメンテナンスされることは、あなたにとって多くのメリットがあることに注意してください。Fedora と EPEL の両方でパッケージをメンテナンスすることを検討すべきです。


=== What do I have to do to get a package removed from EPEL? ===
=== EPEL から削除されたパッケージを取得するのはどうすれば良いですか？ ===


We don't normally remove packages that have already shipped, but if, for example, you build something for EPEL-testing and notice crucial deps are missing we can remove it. Send a mail to epel_signers-members AT fedoraproject DOT org.
我々は普通はリリースしたパッケージを削除することはしません。しかし、例えば、EPEL-testing で何かのパッケージをビルドしていて、重要な依存関係がなくなっていることに気付いたら、我々が削除した可能性があります。epel_signers-members AT fedoraproject DOT org へ連絡してください。


=== What do I need to do if I need to get a updated package quickly into the EPEL proper? ===
=== EPEL の通常プロセスの更新パッケージをすぐに取得する必要があるときはどうすれば良いですか？ ===


Please do not try and push your packages directly to stable unless they are security updates or critical bug fixes. This is <b>enforced</b> by epel rel-eng/signers who will change your request to testing unless your update meets the criteria for pushing to stable.
セキュリティアップデートや重大なバグ修正でない限り、安定版リポジトリへ直接的にパッケージを追加しようとしないでください。更新されたパッケージを安定版リポジトリへ追加するクライテリアがないならば、あなたのリクエストを testing リポジトリへ変更する epel rel-eng/signers によって<b>強制されます</b>


Normal updates <b>MUST</b> spend at least 2 weeks in testing before being pushed to stable. After the initial two weeks you can decide to request stable or let the update wait until it gets sufficient karma in bodhi before pushing.
通常の更新は、安定版リポジトリへ追加される前に testing リポジトリで少なくとも2週間は<b>寝かせなければなりません。</b>2週間後、安定版リポジトリへのリクエストを出すか、追加する前に菩提へ至るカルマを体得するまでその更新を待つかをあなたが決定します。


=== Are games or similar packages not strictly meant for enterprise users allowed and wanted? ===
=== ゲームや同種のパッケージは厳密にはエンタープライズユーザを対象としていないですよね？ ===


Yes. There are people that use EL distributions on their home desktop or similar scenarios because Fedora's release and updates cycle is faster than required for them. Some of those people want to play games or use other non-enterprise oriented software. Having such packages in the repository doesn't affect anyone that uses EL distributions for other needs.
はい。エンタープライズディストリビューションを自宅のデスクトップ等で使用する人々がいます。というのは Fedora のリリースや更新サイクルは彼らの要求しているものよりも速いからです。そのような人々の何人かはゲームや他のエンタープライズではないソフトウェアも使用したいです。そのようなパッケージをリポジトリに追加しておいても、別のニーズでエンタープライズディストリビューションを使用する人へ何の影響も与えません。


== Why don't you simply rebuild all Fedora packages for RHEL that are not part of it? ==
== RHEL が提供していない全ての Fedora パッケージを単純にビルドしないのはどうしてですか？ ==


We require maintainers to take ownership and commit to maintaining the packages in the long term. Merely rebuilding all the packages automatically has higher potential for packages being broken or orphaned.
我々は長期間、パッケージのメンテナンスに所有権とコミット権を持ってくれるメンテナを必要としています。ただ単純に全てのパッケージを自動的にリビルドすることはパッケージを壊してしまう確率が高いです。


= Other questions? =
= ここに質問が見当たらない？ =


You can contact the [[EPEL/FAQ#contact|  EPEL team]]  
[[EPEL/FAQ/Japanese#contact|  EPEL チーム]]へ連絡してください。


----
----
[[Category:EPEL]]
[[Category:EPEL]]

Latest revision as of 00:11, 31 August 2010

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 チームへ連絡してください。

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