rpm5.org versus rpm.org

January 6th, 2008 by Ralf S. Engelschall

Unfortunately, there seems to be still great confusion about the “official” RPM. Although I’m strongly biased, let me tell you my personal point of view…

History: The First 10 Years

RPM originally was the Red Hat Package Manager, as it was invented in 1996/1997 by the Red Hat employees Eric Troan and Marc Ewing. The Red Hat employee Jeff Johnson in 1998 joined this RPM developer team and for over 10 years was the primary RPM developer as Eric Troan and Marc Ewing already very early focused on other projects. RPM since its earliest days in 1996 stayed in a CVS repository, which until 2007 was located on the public server cvs.rpm.org. Even after Jeff Johnson already left Red Hat in 2005 (at the time of RPM 4.4.2) he continued to maintain RPM on cvs.rpm.org in his freetime as RPM already evolved into a Open Source style project, was licensed under the LGPL and since a few years even was officially Red Hat independently named just RPM Package Manager (RPM).

Until spring 2007, Jeff Johnson this way actively released RPM 4 versions up to version 4.4.9 from the original cvs.rpm.org code base while Red Hat previously forked the code base (as of RPM 4.4.2) into a new Mercurial repository hg.rpm.org but stopped any activate development on it for a longer time. Hence there was great confusion about the status quo and the future of RPM, as on one side we had Red Hat with the practically dead www.rpm.org (website) and hg.rpm.org (repository) and on the other side there was Jeff Johnson with the still actively maintained RPM on wraptastic.org (website) and cvs.rpm.org (repository).

Relaunch in 2007

In spring 2007 our OpenPKG GmbH decided to upgrade OpenPKG from the ancient RPM 4.2.1 to a newer version. We immediately got also faced with the confusing situation and had to decide what RPM streamline we want to follow. As we believe in strong code and not politics, we decided to use Jeff Johnson’s code base. It simply was the better one and it was pretty clear that nobody really knows the rather complex RPM better than its long-term developer Jeff Johnson.

Unfortunately, Jeff’s infrastructure was rather weak and the visibility of his RPM was mostly zero outside the usual RPM expert community. This was an obviously too uncertain and weak terrain — onto which we especially not wanted to just base the next version of OpenPKG upon. Hence we decided that in order to use Jeff Johnson’s RPM we first had to support him with a completely new and stronger infrastructure. While we prepared this relaunch from the infrastructure side (where we even migrated the original cvs.rpm.org code base), Jeff Johnson and a larger team of long-term RPM hackers around him proposed a new RPM roadmap towards the next version: the idea of RPM 5 was born and its roadmap later was publically announced once the new infrastructure was in place under rpm5.org.

Then, over a timerange of about 7 months, really a lot of efforts where put into the development of RPM 5, by both Jeff Johnson, the OpenPKG GmbH and all the other long-term hackers in the existing RPM community. For instance, I completely revamped the RPM build environment to make it maximum portable, Jeff integrated XAR format support into RPM, and all people together fixed hundreds of small bugs and unclean areas, etc.

Finally, rpm5.org was able to officially release RPM 5.0.0 just a few days ago. And our OpenPKG in 2008 is finally also in the process of upgrading to this brand-new RPM. We are very happy about the progress and results at rpm5.org

This new RPM 5 IMHO is really the best RPM which ever existed in the last decade as it is the first really portable and vendor-neutral RPM. It also comes out of the original code base, but at the same time this code base was dramatically cleaned up and further improved over the last 7 months.

The “official” RPM Brand

Now just remains the question of many people about which RPM is the “official” one, the “real” one, etc. Well, from my totally biased personal perspective I think it is the new RPM 5 from rpm5.org for the following simple reasons:

  1. RPM 5 from rpm5.org uses the original code base and still drives the original RPM CVS repository — after the infrastructure relocation it just now lives on rpm5.org instead of cvs.rpm.org.
  2. RPM 5 from rpm5.org is still developed by the original long-term RPM developer Jeff Johnson and the larger team of long-term RPM hackers around him. There was also not even a single gap of the code base maintainance for over 10 years now.
  3. RPM 5 provides the larger set of new features and especially addresses the larger scope through its portable cross-platform cross-vendor approach. This way RPM 5 is the more open and future-proof direction.

So, although I personally do not care about this subtle fact very much, if people think it is important to decide who has the “official” RPM, in my opinion those people should decide on their own, but at least keep in mind that code in the Open Source software field usually belongs to those who really care about and improve it in the long-term…

Future of RPM

Nevertheless, I personally really would like to see the two RPM camps to unite as there is no good reason to confuse the community in the long-term. Hence I personally strongly suggest that Red Hat officially lets their few RPM developing employees to join the larger rpm5.org development team. The new rpm5.org infrastructure even could additionally host their older RPM 4.4.2 derived code base if this is wished or even be required. rpm5.org is fully open for them to join at any time…

12 Responses to “rpm5.org versus rpm.org”

  1. RSSub says:

    Thank you for this explanation. I’ve had some problems with rpm in Red Hat Linux and was frustrated to see that they effectively stopped development of rpm. So it’s great that there is a branch with active development. I tried JBJ’s rpm before and found it to be better. But despite this, Red Hat refused to work with him and sabotaged his version of rpm by starting the hg.rpm.org branch… ¿What I’d like to know is their reason for doing this?

  2. Ralf S. Engelschall says:

    Well, I don’t think they wanted to sabotage anything. I think some of their RPM developers just had a favor for Mercurial and so they setup hg.rpm.org. More important would be to understand why they continue to work on the old RPM 4.4.2 derived code base. IMHO it simply is because all their existing packages depend on this old version, they fear the required efforts to upgrade them, etc. So, they now seem to mainly ensure that the particular RPM version which corresponds to their own packages is still available and at least in an acceptable shape. That’s ok, except that I think it goes into the wrong direction in the long-term and also shows the wrong signal to the community. It just can be a short- or mid-term solution for them. In the long-term the best strategy would be to join rpm5.org, maintain the old RPM 4.4.2 for their own purposes just there for some additional time and primarily focus on further development of RPM 5 together with all the other RPM developers at rpm5.org.

  3. sharms says:

    JBJ is, from my personal interpretation of the situation, not a good team player.

    You can reference: https://bugzilla.redhat.com/show_bug.cgi?id=119185

    JBJ believes that rather than error checking, the onus falls on the user. This same use case does not corrupt an apt database, but apparently rpm is too good to check this. You can also see how personable he is from this bug report.

  4. Ralf S. Engelschall says:

    Well, I know this Bugzilla bug report and its long reply chain, of course. Sure, Jeff’s technical point of view was not shared by most people. But this IMHO doesn’t mean that he is a bad team player. I myself know best that as a software developer it is far more important to be able to say a strong “no” instead of saying a weak “yes” just to please others and to avoid a nasty debate. I personally have no problems with developers who keep strongly “fighting” for their position even if great counter-positions exist.

    Also keep in mind that AFAIK others started to call Jeff a “moron” in this reply chain and this way theirself stopped being factual. If I would get called a “moron” I also would stop being happy to solve someones problem, especially if my initial point of view on the solution was different anyway.

    Finally, everybody has good and bad days and I think it is not fair that all people reduce the opinion on Jeff just to a few replies to a over-hyped bug report reply chain. I passively “observed” his RPM development for a longer time and now in-depth also worked with him at rpm5.org for the last 7 months and I cannot share the global opinion which is stated about him.

    Sure, Jeff has strong personal opinions and fights for them. And sure, some of those might look strange from a different point of view. But that’s just usual and part of everybody’s life. The same applies to all other people. So, I personally at least do not have any problem with him as my experience is that he is always willing to really improve RPM if it really makes sense and the request is expressed without being offensive and with strong sustainable technical arguments.

    Finally, AFAIK the database in the cited bug report was not really “corrupt”…

  5. RSSub says:

    @sharms:
    In my view rpm is far superior to dpkg/aptitude because the way it handles dependencies. In rpm a package, say gFoo, which needs the library «bar» depends on libbar.so.x. In Debian, gfoo would depend on a fictional string, the name the Debian packager chose to call the package that contains the library. And if you look at Debian you will see that often the packages have very strange names that don’t correspond to upstream at all. RPM leaves this to higher lever package managers such as yum to figure out which package contains libbar.so.x based on a filelist of all packages (that’s how yum does it), but this allows for more advanced future extensions.
    And also, when you happen to install your own libbar from say source, because you are testing it or you are the developer, rpm figures that everything is right (as it is) but dpkg would scream and apt/aptitude would actually suggest removal of the packages that depend on the library; or if an older version is in the repositories, would complain of internal repository inconsistency and refuse any operation.
    So I consider dpkg fundamentally flawed for this reason.

    The bug described in that bug report about rpm (which I actually never heard of before) also seems to suggest a flaw in rpm, namely that package operations are not atomic. But this doesn’t seem fundamental and could be fixed or perhaps – rpm5 already fixed it. In any case working around it by checking for read-only installation destination is bogus, write errors could be occuring for other reasons, as recently happened to me because of no more free inodes were left on the filesystem, for example. Fortunately, I was not in the middle of a package upgrade…

    @Ralf:
    So is RPM 5 not actually compatible with the main distributions’ [s]rpm files? That would be unfortunate. Also, is any distribution planning to use RPM 5? Perhaps Mandriva? as they currently ship JBJ’s version of rpm from before version 5.

  6. Ralf S. Engelschall says:

    RSSub: RPM 5 is able to read the RPMv4 format SRPMS from the existing distributions just fine. For OpenPKG we are able to smoothly upgrade from RPM 4 to RPM 5 with a simple “openpkg rpm –rebuild openpkg*.src.rpm” followed by an “openpkg rpm -Uvh openpkg*.*-*-*.rpm”. Nevertheless, this does NOT means that RPM 5 is a simple drop-in replacement for RPM 4! That it works such smoothly for OpenPKG is because we specially prepared and ported the environment for RPM 5 and OpenPKG’s SRPMs are all uniformly in content. So, a distribution vendor HAS to adjust his environment a little bit for RPM 5 (think about RPM “macros”, etc). But once this is done, RPM 5 provides a very robust upgrade path.

    Also, all over 1100 existing OpenPKG SRPMs and their content is compatible with RPM 5 without modifications according to our tests.
    Nevertheless, once we have RPM 5 in place we will modify the SRPMs in order to take additional advantage of RPM 5′s new features, of course.

  7. ccj says:

    rpm5 could have least done away with CVS. (Tree-based history rather than file-based history is a must IMHO.)

  8. Ralf S. Engelschall says:

    ccj: for the long-term rpm5.org will upgrade from CVS to one of the more “modern” VCS, of course. But we intentionally suspended this task in Summer 2007 because there were a lot more important issues than fiddling around with the VCS.

    CVS still serves acceptably for existing projects (like RPM, OpenPKG, FreeBSD, etc) even in 2008 as long as the used repository is clean and its use case is well established. Tree-manipulations are cool for new projects were you want or even have to move around whole sub-trees, but you do not benefit very much from this feature in existing stable repositories. Tree-based history is the same.

    So, please don’t misunderstand me: CVS is dead in the long-term, but for mostly no project I personally know of (including rpm5.org) it really is a major show-stopper in the mid-term. That’s mainly because CVS is not as bad as its reputation and many people overestimate the practical drawbacks.

    One really has to require advanced VCS operations to really fail with CVS even in 2008. My experience is that most people, who today tell you that CVS is “just bad” and Subversion & Co are the new kings, never have done advanced VCS operations (like sub-sub-branching, subsequent branch-merging, automatic content verification during commit, etc.) theirself. Sure, it is nice if the VCS provides new features, but for existing projects this is usually not a killer argument.

    For the regular use case CVS is still acceptable as existing projects usually do not change their well established VCS use case at all… ;-)

    PS: There is also the problem that even most of the “modern” VCS have a problem in importing a complex CVS repository because CVS allowed per-file branches, per-file tags, etc. Not all of the “more modern” VCS support such notion and hence a reasonable “upgrade” (which really preserves the history) of an older repository is nothing one can “just do”…

  9. Michel S. says:

    @RSSub:

    Actually, RPM automatically lists any *.so.* files as virtual provides for the package, and so resolving those are fast. It’s when yum needs to solve ‘who owns /usr/share/foo’ or any other non-library file that it has to consult the filelist, and thus Fedora’s packaging guideline, for example, recommends avoiding this unless absolutely necessary.

  10. dreux says:

    Dear Mr. Engelschall:

    I am a TECHNOPHOBE, at best; But I was extremely plesead and impressed with the stirring presentation of knowledge and ardent devotion to perfection that is evident throughout. And yet, it is also clearly comprehensible and humorou too.

    How fortuitous for me to have had the opportunity of perusing your site. It was enlightening and elucidating.

    Thank you.
    D

  11. Simon J Mudd says:

    I recently added some comments about my “small” view of rpm. Many of the changes you patched into OpenPKG’s rpm would be great for a wider audience. I assume that some of this has gone into rpm 5? It’ll be interesting to see how rpm develops and as you say having various rpm forks is not helpful to anyone.

  12. Mark Page says:

    When is version 6 coming out?

Leave a Reply