[packagers] What's up with RPMforge?

Morten Kjeldgaard mok at bioxray.dk
Tue Feb 27 13:27:14 CET 2007

Excuse me for raising this question here, but I am getting more and more 
of an impression that RPMforge is stagnating, and I find that extremely 
worrisome. The lack of traffic on this, the packagers list, the 
never-updated website, and the absence of the primary driving forces 
(Dag, Dries, Matthias) on various forums all appear to be signs that 
things are not developing as we all wish for.

If this is indeed the case, and if the primary forces of RPMforge are 
getting bogged down with work, why not have a discussion here on this 
forum of what can be done about it? I am sure there are several readers 
who would like to help out with various chores, and lots of people, 
myself included, have many packages that could be maintained within the 
RPMforge framework. I believe that was part of the initial vision as 
well. We all have lots of things to do, I find myself tied up with other 
chores for months at a time, but once in a while I have some spare time 
that I would like to spend giving back to the Linux community.

I recently installed Ubuntu on a spare workstation. It was a big 
pleasure, the distro works very nicely and is beautifully designed. You 
download a CD, and when the machine is up, you can install whatever you 
want via apt-get. And particularly, everything is available from a 
single repository. You don't need to fish around in a dozen of 
more-or-less incompatible repos for the stuff you need. And perhaps even 
breaking software in the process, as many of the repos seem to favour 
packaging the same software slightly diffently and with inconsistent 
dependency schemes. So even if I don't have the slightest sympathy for 
ESR's pathetic whining last week (everybody else knows that you have to 
pick your repos with care) it does raise a point.

I am _not_ considering a switch to Ubuntu. Those of you who have tried 
to author .deb packages know that it is an extremely tedious and 
complicated process, compared to authoring an RPM package. Ironically, 
the easy of creating an RPM package has resulted in the proliferation of 
RPM 2nd and 3rd party distributions to the extent that they are no 
longer compatible. Recall the fftw/fftw3 debate.

RPMforge has long been my hope for the way out of this mess. However, 
RPMforge has IMHO been hampered by the need to support several different 
distributions. In particular, Fedora is a moving target, and a lot of 
effort goes into the cerimonial semi-annual recompilation of all the 
packages. Perhaps this would be a good time to direct RPMforge towards a 
single, stable, and well maintained mother distribution, as for example 
CentOS (RHEL). There are other advantages to dropping Fedora support, 
but I don't think we should get deep into that discussion at this point.

To ensure a uniform packaging and dependency policy, I would suggest 
keeping one eye on the Debian distributions. They have already worked 
out a a naming dependency scheme that _works_.


Morten Kjeldgaard, Asc. professor, Ph.D.
Department of Molecular Biology, Aarhus University
Gustav Wieds Vej 10 C, DK-8000 Aarhus C, Denmark
Lab +45 89425026 * Mobile +45 51860147 * Fax +45 86123178
Home +45 86188180 * http://www.bioxray.dk/~mok

More information about the packagers mailing list