- General Information
- Installation and Configuration
- Giving Feedback
- Compatibility and mixing repositories
- Rebuilding Packages
- Miscellaneous Items
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).
- Current packagers:
Matthias Saou, Dag Wieers and Dries Verachtert
- Supported distributions:
- Supported/tested architectures:
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: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.
Number of unique RPM packages: 0 (distro-sum)
Number of unique RPM packages: (distro-independent)
Number of unique source packages:
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 Fedora Core Linux 8 - Fedora Core Linux 7 - Fedora Core Linux 6 Zod Fedora Core Linux 5 Bordeaux Fedora Core Linux 4 Stentz Unsupported Fedora Core Linux 3 Heidelberg Fedora Core Linux 2 Tettnang Fedora Core Linux 1 Yarrow Red Hat Linux 8.0 Psyche Red Hat Linux 6.2 Zoot
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:
- We don't replace base libraries or important core packages for repositories that are not EOL.
- Everything we do is open, you can download the SPEC files, you can see what we changed, you can rebuild it yourself.
- Report your problems, and we will fix them as soon as possible. Send us your bugfixes and we fix them instantly.
- We communicate with developers directly and try to have things fixed upstream.
- If you experience repository conflicts, we'll work with other repositories to fix them (when possible).
- We already have a huge userbase that is testing and providing improvements and bugfixes.
- We provide packages for a variety of distributions and architectures, each of these userbases are providing us with useful feedback.
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.
- By sending us feedback and improvements, see C1
- By helping other users on the mailinglist
- By sending us a small thank you mail, that's always appreciated :)
- By sending us a little present:
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 packages directory. The directory listing will also indicate the distribution.
The packages are all signed with this GPG key.
B2. How to configure to use RPMforge ?
It's very easy. Just install the latest rpmforge-release 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:
- Red Hat Enterprise Linux 5 / i386:
- Red Hat Enterprise Linux 5 / x86_64:
- Red Hat Enterprise Linux 4 / i386:
- Red Hat Enterprise Linux 4 / x86_64:
- Red Hat Enterprise Linux 3 / i386:
- Red Hat Enterprise Linux 3 / x86_64:
- Red Hat Enterprise Linux 2 / i386:
- Red Hat Linux 9 / i386:
- Red Hat Linux 7.3 / i386:
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: http://dag.wieers.com/packages/apt/. The configuration of Apt is inside the rpmforge-release package.
If you've done that, the rest is simple. Update the local repository meta-data by doing:
apt-get updateYou can upgrade your system with the latest packages with:
apt-get upgradeAnd 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 cleanRemember 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 synapticOr download it from: http://dag.wieers.com/packages/synaptic/
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: http://dag.wieers.com/packages/yum/
The configuration of Yum is inside the rpmforge-release package. You need to install it yourself.
If you've done that, the rest is simple. Upgrade your system by doing:
yum updateYou 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 availableFrom time to time you may want to save some diskspace:
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/dagNow start up2date to update your system, by doing:
C1. Where can I report problems or improvements ?
You can send problem reports or improvements to any of my packages to: firstname.lastname@example.org.
To lower the burden of my workload, I would appreciate if you could:
- Investigate into the problem, or think about a good implementation for your improvement and send me and analysis of your findings. This will greatly speed up a fixed/new package.
- Look at the scripts/config files and documentation that ship with
the package, you can do that using:
rpm -qc <package>resp.
rpm -qd <package>In most cases a solution may be at hand without needing my help.
- Check if I'm the packager. In some cases I'm not the authority of a package. In that case, address your mail to the real packager and include me as a recipient.
- Think about whether this is a packaging problem or a problem with
- If it is a software problem/suggestion, talk directly to the developers. Point them at the public buildlogs and the SPEC files so that they can analyse the problem much faster.
- If it is a packaging problem, let me know how I can fix it.
- If you're unsure, mail the developers and include me too. Address only one of us so that there is no confusion about who's in charge.
If you have a general question, a compatibility problem or want to discuss something with other users, you can post on the RPMforge users mailinglist.
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 RPMforge suggest mailinglist. 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 RPMforge packagers mailinglist and join the RPMforge svn-commits mailinglist
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 a policy 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 this policy. 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.rpmThe 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.rpmIf 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.rpmZ1. 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.