Updated: September 3, 2011

If you read my Scientific Linux 6.1 Carbon review a few weeks back, you will learn the following, somewhat disturbing fact - by enabling additional repositories, you might render your system inoperable by application version conflicts. So you face a big problem. On one hand, you need the extra stuff. On the other, there's the risk of Armageddon spoiling your desktop experience. So what do you do?

Well, you come here and read this article, which teaches you how to avoid the classic mistakes, keep your system in a minty condition and still get all the cool stuff you need from the extra repositories. Sounds good, no? So please read on.

Proceed slowly, my friend!

This is step number one to using additional repositories. If you visit the Scientific Linux forums, you will learn there's a handful of extra software sources waiting for you. As an eager user, you might be tempted to enable them all. But no.

Here's the recipe to testing new repositories:

• Enable ONE repository. Then, perform a search for the missing stuff. If it's all there, good. If not, disable the repository you just added and try another. Finally, settle down for the one that provides most hits for your queries, even if it does not satisfy them all.
• Once this is done, install ONE item of choice, preferably a media plugin. After that, let the system be for a few days until you get a prompt from the system that there are updates available. Perform the update cycle to make sure there are no conflicts or errors of any kind. If you get this far, it's good, meaning you are most likely okay with the software source you chose.
• If you get conflicts, disable the repository, uninstall the program you used for testing, retry with another repository. This testing step, while tiring, will become even more important once you start testing multiple repositories at the same time.
• Moreover, beware the testing channels for your software sources, as they will most likely include the same software, only with higher and newer versions. This can cause conflicts. Best avoid testing if you're a casual user.

Now that we have the sane and safe rules in places, let's learn how to enable the repositories, including automated and manual changes.

How to enable extra repositories

There are several ways to do this. The simplest and safest is using the Add/Remove Software utility, hereby known as the automatic approach. Open it. In the left pane, expand the SL Addons section, YUM Repositories. There will be four repositories available, RPMforge, EPEL, ElRepo and ATRPMS.

Select any one and click Apply. After the utility refreshes, go to System, Software Sources and examine the available channels. Please note the Testing versus ordinary channels. Moreover, avoid selecting more than one extra repository at this time. In fact, you can install all four available extras, but then deselect any three for the duration of your testing.

My recommendation is to begin with RPMforge, then ATRPMS, then EPEL. Moreover, my testing shows the three coexist and cooperate well together, but that does not excuse you from thorough testing of your own.

A less convenient way of enabling repositories is manually. Under /etc/yum.repos.d, you can create the repository configuration files, suffixed with repo. Let's take a look at what some of these sources look like, including some screenshots and code. This is not a blind copy & paste, so mind the little details please!

RPMforge

### Name: RPMforge RPM Repository for RHEL 6 - dag
### URL: http://rpmforge.net/
[rpmforge]
name = RHEL $releasever - RPMforge.net - dag
baseurl = http://apt.sw.be/redhat/el6/en/$basearch/rpmforge
mirrorlist = http://apt.sw.be/redhat/el6/en/mirrors-rpmforge
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge
enabled = 1
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1

[rpmforge-extras]
name = RHEL $releasever - RPMforge.net - extras
baseurl = http://apt.sw.be/redhat/el6/en/$basearch/extras
mirrorlist = http://apt.sw.be/redhat/el6/en/mirrors-rpmforge-extras
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge-extras
enabled = 1
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1

[rpmforge-testing]
name = RHEL $releasever - RPMforge.net - testing
baseurl = http://apt.sw.be/redhat/el6/en/$basearch/testing
mirrorlist = http://apt.sw.be/redhat/el6/en/mirrors-rpmforge-testing
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge-testing
enabled = 0
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1

ATRPMS

[atrpms]
name=Red Hat Enterprise Linux 6 - $basearch - ATrpms
failovermethod=priority
baseurl=http://dl.atrpms.net/el6-$basearch/atrpms/stable
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-atrpms

[atrpms-debuginfo]
name=Red Hat Enterprise Linux 6 - $basearch - ATrpms - Debug
failovermethod=priority
baseurl=http://dl.atrpms.net/debug/el6-$basearch/atrpms/stable
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-atrpms

[atrpms-source]
name=Red Hat Enterprise Linux 6 - $basearch - ATrpms - Source
failovermethod=priority
baseurl=http://dl.atrpms.net/src/el6-$basearch/atrpms/stable
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-atrpms

EPEL

[epel]
name=Extra Packages for Enterprise Linux 6 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

[epel-debuginfo]
name=Extra Packages for Enterprise Linux 6 - $basearch - Debug
#baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch/debug
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-6&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
gpgcheck=1

[epel-source]
name=Extra Packages for Enterprise Linux 6 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/6/SRPMS
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-source-6&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
gpgcheck=1

Repository keys

However, you CANNOT yet use the configuration files without importing the repository keys. So to manually configure repositories, you will need a URL pointing to the GPG keys or import them in a different manner, like wget, import and alike. Worry not, exact instructions coming just below.

Therefore, create the configuration files, then import the keys, then use yum. The key import is done using the appropriately named rpm --import command.

rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt

rpm --import http://packages.atrpms.net/RPM-GPG-KEY.atrpms

rpm --import http://keys.gnupg.net:11371/pks/lookup?search=0x217521F6&op=get

Notice: The EPEL key is stored under the Fedora Project GPG keys page.

More information on these repositories and how they can be configured and installed, including importing keys and/or setting them up using RPM package management is available in this Scientific Linux forum thread. And these links are also useful:

http://wiki.centos.org/AdditionalResources/Repositories/RPMForge

http://atrpms.net/documentation/install/

http://fedoraproject.org/wiki/EPEL

If you choose to use URLs rather than locally stored keys, the first time a new repository is used, you will be asked to confirm importing the repository key. So you can do all that as a convenience rather than hacking the command line to death if you're not comfortable with the task.

Furthermore, pay attention ...

In all cases, pay attention to gpgcheck and enabled fields. You want both set to 1, meaning the repositories will be enabled and checks performed for the key. Moreover, if necessary, pay attention to the CPU architecture, i386 versus x86_64. There's also the protect field, but we will discuss that in a jiffy.

Some additional repositories

Another source of interest might be the PUIAS repository. This source contains programs you won't find in some of the others, but beware conflicts. These might come to bear after you have installed a dozen applications with a hundred dependencies, and you don't want to start fixing by removing programs one by one. PUIAS looks like something this:

[PUIAS_6_addons_2]
name=PUIAS addons Base $releasever - $basearch - 2
#mirrorlist=http://www.puias.princeton.edu/data/puias/$releasever/$basearch/os/Addons/mirrorlist
baseurl=http://www.math.ias.edu/data/puias/$releasever/$basearch/os/Addons
gpgcheck=1
gpgkey=http://www.math.ias.edu/data/puias/6/i386/os/RPM-GPG-KEY-puias

Replace the architecture string if necessary. Notice the key is taken directly from the website, but it will be imported the first time you're asked to confirm the use of the repository. Alternatively, you can use rpm --import, then replace the gpgkey directive with the path to /etc/pki/rpm-gpg/<PUIAS key>.

Conflicts!

Suddenly, when running the update manager, you may see this:

I got this mixing ATRPMS and PUIAS, failing on some ugly [sic] plugins. So now what? Well, first, as a workaround, you can always disable the repository channels to get your software management underway, but this also means that effectively some programs already installed will not receive updates. And there's another way.

Repository priorities & protection

You can avoid some of the conflicts by setting priorities to your repositories so that packages are sourced in a certain order, or you can protect some of the sources, so their content cannot be destroyed by a conflicting package update from another.

The two packages required are yum-protectbase and yum-priorities. Install them:

yum install yum-protectbase yum-priorities

After these are installed, in any repository configuration file, you can add the priority= directive or protect= directive to make the appropriate change. Again, this requires testing and tweaking.

Here's a nice article explaining how to protect repositories from mangling your software base with applications from conflicting sources. And here's a nice article explaining how to prioritize your repositories.

Conclusion

There you go, a somewhat geeky and definitely not trivial recipe to happy Linuxing with Scientific. It pains me that repository conflicts can exist and come to bear in such a trivial manner, but this is something that distro developers need to sort. The best solution would be to make the official repositories as rich as possible, so they include everything. Then, there will be no need for dangerous tweaking.

On the bright side, you learned about smart software management, how to digest problems one bite at a time, enabling repositories in an automated manner and manually, importing GPG keys, protecting your repositories, prioritizing updates, and more. Hopefully, this was a valuable lesson. Have fun, children of the Internets!

P.S. This article is also applicable for RHEL, CentOS and Fedora users!

Cheers.