More software for Enterprise Linux - the EPEL repo

quaid

Just curious if people use or contribute to the Extra Packages for Enterprise Linux repository?

http://fedoraproject.org/wiki/EPEL

This add-on repository is a set of community-supported packages that are rebuilt from the Fedora software repository. It has packages for Drupal, Moodle, git, many Perl modules, and so on. There are over 4000 EL5 and ~1800 EL4 packages registered for i386, for example.

These packages are intentionally supported, that is, it is not just a rebuild of all Fedora packages with maintainers who don't care about Enterprise Linux users. Instead, these package maintainers specifically want to support software in a style similar to the RHEL maintenance.

EPEL tries to focus on stability, updating software in a similar philosophy with Red Hat around RHEL. This is different from the rest of Fedora, where updating to the latest from upstream is the norm. EPEL updates are more likely to be conservative, security and bug fixes over feature enhancements.

My favorite thing about EPEL is how it lets an organization directly contribute to an upstream about only the software that matters to them. If you have a set of Perl modules you use that are not in RHEL, put them in EPEL. You gain instant community collaboration, only have a small set of packages to maintain, and you get a ton of potential and real QA on those packages.

isaac

I use EPEL all the time at work on our RHEL4 and RHEL5 boxes. One of the first things I do on a new RHEL install is add the repo for it.

deploylinux

Yes, we add the following repositories to all RHEL5 installs:

EPEL
FC6 Extras
freshrpms

These seem to be the main "safe" general purpose repo's.

atreyu

quaid wrote:

Just curious if people use or contribute to the Extra Packages for Enterprise Linux repository?

http://fedoraproject.org/wiki/EPEL

This add-on repository is a set of community-supported packages that are rebuilt from the Fedora software repository. It has packages for Drupal, Moodle, git, many Perl modules, and so on. There are over 4000 EL5 and ~1800 EL4 packages registered for i386, for example.

These packages are intentionally supported, that is, it is not just a rebuild of all Fedora packages with maintainers who don't care about Enterprise Linux users. Instead, these package maintainers specifically want to support software in a style similar to the RHEL maintenance.

EPEL tries to focus on stability, updating software in a similar philosophy with Red Hat around RHEL. This is different from the rest of Fedora, where updating to the latest from upstream is the norm. EPEL updates are more likely to be conservative, security and bug fixes over feature enhancements.

My favorite thing about EPEL is how it lets an organization directly contribute to an upstream about only the software that matters to them. If you have a set of Perl modules you use that are not in RHEL, put them in EPEL. You gain instant community collaboration, only have a small set of packages to maintain, and you get a ton of potential and real QA on those packages.

whoa, can't believe i've missed that one. adding to repos now...

0x83

Great post! Just wanted to note that EPEL is not supported with Red Hat and your RHEL support contract. If GSS is able to find a solution with EPEL, it is not uncommon to suggest to the customer to go that route.

I would also suggest running EPEL and RPM Fusion if you need your extra packages.

"RPM Fusion provides software that the Fedora Project or Red Hat doesn't want to ship. That software is provided as precompiled RPMs for all current Fedora versions and Red Hat Enterprise Linux 5; you can use the RPM Fusion repositories with tools like yum and PackageKit.

RPM Fusion is a merger of Dribble, Freshrpms, and Livna; our goal is to simplify end-user experience by grouping as much add-on software as possible in a single location. Also see our FoundingPrinciples. "

http://rpmfusion.org/

I would hold off including rpmforge along with those two repos. In latest testing (check date of this post) they do not play well with each other and there are a lot of RPM conflicts.

~rp

isaac

0x83 wrote:

I would hold off including rpmforge along with those two repos. In latest testing (check date of this post) they do not play well with each other and there are a lot of RPM conflicts.

~rp

Seconded, I've recently seen depsolving issues when rpmforge is thrown into the mix.

umairbari

Mixing repos is never a good practice.

quaid

Fortunately, EPEL is by definition non-conflicting.