Here you can find answers to Frequently Asked Questions. Bear with me as I update and improve this page.
  1. General Information
  2. Installation and Configuration
  3. Giving Feedback
  4. Compatibility and mixing repositories
  5. Rebuilding Packages
  1. Miscellaneous Items
A1. What is the Dag RPM Repository ?
It grew out of my personal collection of RPMs, after discovering apt for RPM and the FreshRPMS repository of Matthias Saou, I ended up opening up my own packages and packaging a whole lot more. Since 2005 we've merged our repositories, provided packages for several Red Hat based distributions and a handful of architectures.

The new RPMforge.net project is now working towards providing a better infrastructure and tools to allow more people to help out and expanding our list of supported distributions. We hope to integrate other packagers work and get rid of duplicated efforts and resources (bug-reports, patches, developer time and knowledge).
A2. What distributions and architectures are supported ?
Here's a small overview with the total numbers, the number of packages per distribution and per architecture.
Total number of all (S)RPM packages:
Number of unique RPM packages: (distro-sum)
Number of unique RPM packages: (distro-independent)
Number of unique :
Supported#pkgs - i386#pkgs - x86_64
Red Hat Enterprise Linux 5 Tikanga
Red Hat Enterprise Linux 4 Nahant
Red Hat Enterprise Linux 3 Taroon
Red Hat Enterprise Linux 2.1 Pensacola
Red Hat Linux 9 Shrike
Red Hat Linux 7.3 Valhalla
Supported by Dries
-')?>
-')?>
Zod')?>
Bordeaux')?>
Stentz')?>
Unsupported
Fedora Core Linux 3 Heidelberg
Fedora Core Linux 2 Tettnang
Fedora Core Linux 1 Yarrow
Psyche')?>
Zoot')?>
Please note that I invest my time into Red Hat's enterprise products. (Enterprise Linux) and compatible distributions like CentOS. Although I try to make sure older releases work too they are basicly a free extra of my buildsystem. They may have not been tested as thoroughly, but have no known issues. Please report any issue or improvement you have.

In the future I may end supporting RH7.3 and RH9. At the moment I have not made any decisions yet, it's all about how I use my resources. If you interested to continue support for RH62, RH80, FC1, FC2 or FC3 please contact me.

A3. Why should I use RPMforge repositories ?
There are many good repositories that you can use. Here are some advantages to our repositories: A4. How can we thank ?
This is no longer a one person effort, so depending on why you are thankful you may have to address another person :)

In general there are several ways to thank us and help the project. B1. How to use this repository ?
Most people use this RPM repository together with a tool that allows to automatically download an install RPM packages and resolve dependencies. You have the choice of different tools, like Apt, Smart, Yum, up2date or Red Carpet.

However if you occassionally want to download something, we've made sure the packages are tagged with a proper distribution-tag so you can easily pick the right package for your distribution from the . The directory listing will also indicate the distribution.

The packages are all signed with .

B2. How to configure to use RPMforge ?
It's very easy. Just install the latest package for your distribution and architecture.

This will automatically install the configuration and GPG keys that are for safely installing RPMforge packages.

Please select the correct command from the following list: B3. How do I use Apt ?
Apt originally was developed by the Debian project to work together with DEB packages. Since there are not many functional differences between RPM and DEB packages, Conectiva ported Apt to use RPM.

To install Apt, download the latest package for your distribution from: . The configuration of Apt is inside the package.

If you've done that, the rest is simple. Update the local repository meta-data by doing:

apt-get update

You can upgrade your system with the latest packages with:

apt-get upgrade

And finally you can add new software by typing:

apt-get install <name of package>

Or search for software in the local repository meta-data:

apt-cache search <keyword> apt-cache show <name of package>

From time to time you may want to save some diskspace:

apt-get clean

Remember to update your local repository often before upgrading or installing software, so that you can enjoy the latest and greatest. Some people rather use a graphical program to select and install packages. Apt has a nifty graphical front-end, called Synaptic. You can install it by doing:

apt-get install synaptic

Or download it from:

B4. How do I use Yum ?
Yum is an update-tool written in python. The advantage of Yum is that it is written in Python. The disadvantage is that there are many versions of Yum, and only recent versions work with recent distributions. If you like to use a single tool across all distributions, it's better to use Apt.

Yum is usually already installed if you're running Fedora Core. In case you are using Red Hat Enterprise Linux or an older Red Hat Linux distribution. You can find Yum at:

The configuration of Yum is inside the package. You need to install it yourself.

If you've done that, the rest is simple. Upgrade your system by doing:

yum update

You can add new software by typing:

yum install <name of package>

Or update installed software:

yum update <name of package>

Or search for software in the local repository meta-data:

yum search <keyword>

Or simply list all available software:

yum list available

From time to time you may want to save some diskspace:

yum clean


B5. How do I use up2date ?
up2date is a tool written and shipped by Red Hat to update your system with the latest available updates. Starting with Red Hat Enterprise Linux 3 and Fedora Core 1 it can also be used with Apt and Yum repositories. Install up2date from your Red Hat installation and then add one of the following statements to /etc/sysconfig/rhn/sources:

### Dag RPM Repository for Fedora Core yum dag http://apt.sw.be/fedora/3/en/$ARCH/dag yum dag http://apt.sw.be/fedora/2/en/$ARCH/dag yum dag http://apt.sw.be/fedora/1/en/$ARCH/dag ### Dag RPM Repository for Red Hat Enterprise Linux yum dag http://apt.sw.be/redhat/el4/en/$ARCH/dag yum dag http://apt.sw.be/redhat/el3/en/$ARCH/dag

Now start up2date to update your system, by doing:

up2date -u


C1. Where can I report problems or improvements ?
You can send problem reports or improvements to any of my packages to: .

To lower the burden of my workload, I would appreciate if you could: C2. Where can I discuss about these packages ?
If you have a general question, a compatibility problem or want to discuss something with other users, you can post on the .

C3. Where can I contribute packages ?
If you have made packages yourself, but want them to be part of the RPMforge repository, please send a mail to the . And add a reference to the source RPM or SPEC file. Also state if you want to maintain this package in the future or not.

If you are interested to help out in the development of packages or follow the discussions, you can join the and join the

D1. What about compatibility with Fedora ?
My Fedora repository is designed to work 100% with the Fedora Core packages. You should have no problems applying these packages to Fedora Core. If you do find a problem, please let me know asap so that I can look into it.

Beware that this repository is not compatible with fedora.us or livna.org. I would like to be compatible with these repositories, but they have to not work together with other repositories. Compatibility works in 2 directions and if one party is refusing to care, it's impossible to make it work. I still hope fedora.us and livna.org change their minds and drop . In the meantime I advise you not to use these 2 repositories.

One of the many examples is that they introduce new packages that already existed in my repository for 2 years. Sadly, they then use other package names so that it clashes with my already available packages. In many cases it is hard or even impossible to work around that. With other repositories we care about such clashes and discuss and prevent this from happening. Other repositories are willing to fix inter-repository compatibility, fedora.us and livna.org are not.

Other reasons for not choosing fedora.us packages: only i386 is supported (no x86_64, pcc, sparc or alpha packages), only Fedora Core packages are provided (no support for RHEL, Yellow Dog, Aurora, SuSE), no open development or publicized SPEC files (following development is very hard), only resulting source RPMs are availble.

D2. What repositories can I mix ?
Most repositories should already work well together. If you do find a problem, the best thing to get this fixed is by reporting this to both repository maintainers. If it is a genuine problem, it will be fixed promptly.

The repositories I mix myself are: FreshRPMS, Dries, NewRPMS and PlanetCCRMA.

FreshRPMS, PlanetCCRMA, Dries and DAG (RPMforge.net) build their packages together from the same sources. This ensures much greater cooperation and compatibility and will eventually lead to a merger. If you are a skilled packager and interested to join, don't hesitate to contact us. E1. How to rebuild packages ?
The best way to rebuild these packages for a distribution is to specify what distribution you're building for. RPM has no knowledge in what distribution it is operating and therefor we rely on the rebuilder to tell it:

rpmbuild --rebuild --define 'dist fc2' package.src.rpm

The following keywords are allowed: rh6, rh7, rh8, rh9, el2, el3, el4, fc1, fc2, fc3, yd2, yd3, yd4

In some occasions we allow to add or remove features. look inside the SPEC file for more details.

rpmbuild --rebuild --with mysql --without db3 package.src.rpm


E2. How to rebuild kernel-module packages ?
When rebuilding kernel-module packages, it is important to have the correct build environment set up. You need to have the kernel-source package installed. If you have several kernel-source packages installed, you have to tell rpmbuild which one to use:

rpmbuild --rebuild --define 'kernel 2.4.21-15.0.4.EL' package.src.rpm

If you don't do this, rpmbuild may take the last one that rpm -q returns.

If you're simply rebuilding against the current kernel, this should suffice:

rpmbuild --rebuild --define 'kernel $(uname -r)' --target $(uname -m) package.src.rpm

Z1. Why are packages now tagged 'rf' ?
Since February 2004 I've been merging my packages with FreshRPMS and Dries. Since our aim is to merge our packages, we decided as a next step to tag our packages alike. This common repotag will indicate that the packages are build from a common repository.

The rf repotag is short for RPMforge, which is the name of the new project.