From Fedora Project Wiki

< EPEL‎ | FAQ

Revision as of 13:52, 8 May 2010 by T2y (talk | contribs) (How can I install the packages from the EPEL software repository?)

Contents

EPEL とは何?

エンタープライズ Linux 用の拡張パッケージ(EPEL) は、 Red Hat Enterprise Linux (RHEL) 向けの高品質なアドオンパッケージであり、CentOS や Scientific Linux (SL) のような RHEL からスピンオフしたディストリビューションと互換性のある、Fedora プロジェクトで有志によって作成されたパッケージになります。Fedora は RHEL のアップストリームであり、EPEL のアドオンパッケージは主に RHEL 向けにビルドされた Fedora リポジトリをソースとしています。

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

Fedora Project はどうして 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 リリースと互換ディストリビューションのアドオンパッケージを提供します。RHEL 3 や 2.1 向けのパッケージは、errata support policy によると、メンテナンスフェーズになるので提供されていません。Fedora をベースとするパッケージは、適切にメンテナンスするのが難しい RHEL 3 や 2.1 のリリースで利用できる古いバージョンのパッケージをビルドしないでしょう。

How is EPEL different from other third party repositories for RHEL and derivatives?

  • 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 adheres to the well documented 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?

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.

Does EPEL replace packages provided within Red Hat Enterprise Linux or layered products?

No. EPEL is purely a complimentary repository that provide add-on packages.

What is the policy on updates for packages in EPEL?

Refer to the EPEL package maintenance and updates policy for all the details.

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.

How long are EPEL packages updated?

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 errata support policy .

How can we be sure that someone will maintain the packages until end of life of the distribution the packages were built for?

The only way to be sure is to do it yourself, which is coincidentally the reason EPEL was started in the first place.

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 generic description that you can use as the basis for adding to a job description.

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.

What if my ISV/IHV wants to maintain a package in EPEL?

Software and hardware vendors are encouraged to get involved in EPEL. For more information, read the ISV/IHV Perspective.

Using EPEL

EPEL リポジトリからどうやってパッケージをインストールしますか?

RHEL4RHEL5 に RPM パッケージのリポジトリがあります。

リポジトリパッケージは yumup2date を使用するための repo ファイルをインストールします。その後、EPEL リポジトリも含めて、通常の方法でパッケージをインストールすることができます。

su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm'
...
su -c 'yum install foo'

Where is the software repository located?

EPEL packages are located at master mirror . There are mirrors available at mirror list .

Where can I find help or report issues?

You can find help or discuss issues in the epel-devel-list or #epel Freenode IRC channel. Report issues against EPEL to via bugzilla .

How do I know that a package is a EPEL package

All EPEL packages are signed with the EPEL gpg-key. The public key with id 217521F6 is part of the epel-release package; yum will ask you to import it the first time you install a EPEL package.

Is EPEL "upstream" or "an official package repository" (like Fedora Extras was)?

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.

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.

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.

Why doesn't EPEL use 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.

How can I find out if a package is from EPEL?

If you want to find out if a package comes from EPEL, use a query such as this:

$ 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

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.

Is EPEL willing to cooperate with other third party repositories?

EPEL is always willing to discuss cooperation with other parties and repositories and encourages maintainers to do so whenever possible.

What about compatibility with other third party repositories?

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.

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 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.

Contributing to EPEL

General

Who can contribute to 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.

Questions specific to existing Fedora contributors

How do I get my packages into EPEL?

You have to follow the same process as Fedora except that you can request an EPEL branch, tag, and build.

How do I request a EPEL branch for an existing Fedora package?

Please follow the usual Fedora method with a Package Change Request .

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?

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.

I maintain a package in Fedora and want to maintain packages in EPEL, too, but I don't have a RHEL subscription for testing?

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.

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?

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 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.

You may want to look into formalizing your packaging role in your company or other organization. If you can do that, this 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.

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.

How do you make sure that packages in EPEL and in Fedora do not split?

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).

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.

Will my packages from Fedora simply build unchanged on EPEL5

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.

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.

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.

Here is a list of packages that are only part of the client:

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

These are only part of the 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

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. 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.

How can I know which packages are part of RHEL?

Look at the rebuilds trees such as CentOS, or 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

See here how to get a Fedora package in EPEL.

Should I take old or latest software as a base for 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 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.

Miscellaneous

I want to get a package into EPEL. What do I have to do?

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.

Is it possible to get a package only into EPEL and not Fedora?

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.

What do I have to do to get a package removed from 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.

What do I need to do if I need to get a updated package quickly into the EPEL proper?

Please do not try and push your packages directly to stable unless they are security updates or critical bug fixes. This is enforced by epel rel-eng/signers who will change your request to testing unless your update meets the criteria for pushing to stable.

Normal updates MUST 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.

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.

Why don't you simply rebuild all Fedora packages for RHEL that are not part of it?

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 team