The launch of RPM 5.0 [LWN.net]

By Forrest Cook
January 9, 2008

Stable version 5.0.0 of RPM, the rpm package manager, formerly known as the Red Hat package manager, has been announced. RPM5 is a fork of RPM; it should not be confused with the version used by Red Hat, Fedora, SUSE, and others, which can still be found at rpm.org.

The project description states:

RPM is a powerful and mature command-line driven package management system capable of installing, uninstalling, verifying, querying, and updating Unix software packages. Each software package consists of an archive of files along with information about the package like its version, a description, and the like. There is also a library API, permitting advanced developers to manage such transactions from programming languages such as C, Perl or Python.

Traditionally, RPM is a core component of many Linux distributions, including Red Hat Enterprise Linux, Fedora, Novell SUSE Linux Enterprise, openSUSE, CentOS, Mandriva Linux, and many others. But RPM is also used for software packaging on many other Unix operating systems like FreeBSD, Sun OpenSolaris, IBM AIX and Apple Mac OS X through the cross-platform Unix software distribution OpenPKG. Additionally, the RPM archive format is an official part of the Linux Standard Base (LSB).

The RPM5 developers certainly have a high opinion of what this release brings:

The relaunch of the RPM project in spring 2007 and today's following availability of RPM 5 marks a major milestone for the previously rather Linux-centric RPM. RPM now finally evolved into a fully cross-platform and reusable software packaging tool.

RPM Version 5.0.0 differs in numerous ways from other versions. As noted above, the project aims to be cross-platform. Much of the code is said to have been cleaned up and numerous bugs have been fixed. The RPM build process has been completely rewritten to improve portability. The code base has been ported to all of the major UNIX-based platforms and Windows. All of the most widely used open-source and proprietary compilers are now supported. Supported compression formats now include bzip, bzip2 and LZMA. Initial support has been added for XAR, the XML Archive file format, while support for the old RPMv3 format has been removed. New package specification features have been added and RPM 5 can now automatically track vendor distribution files.

In the last several years, the RPM project has been plagued by a bit of controversy. The issues mainly centered around maintenance of the code and which version was used by Red Hat. In August, 2006, LWN asked Who maintains RPM? More recently, Ralf S. Engelschall from the OpenPKG distribution has posted a blog entry that discusses the project's history and considers which version is "official". Lastly, the initial RPM 5.0.0 announcement on LWN produced some lively discussion of RPM issues.

The much-trumpeted release of RPM5 seems unlikely to put an end to this controversy, to say the least. RPM5 would appear to have a certain amount of development energy and momentum, but it is not used by any major distributions and it is not at all clear that this will change; in particular, Red Hat and Fedora seem highly unlikely to drop their version of RPM for RPM5. So this fork - and the bad feelings that go along with it - will probably persist indefinitely. That's not what anybody would wish for a crucial (and normally relatively boring) system tool like rpm.

(Log in to post comments)

The launch of RPM 5.0

Posted Jan 10, 2008 17:10 UTC (Thu) by jengelh (subscriber, #33263) [Link]

>RPM Version 5.0.0 differs in numerous ways from other versions. As noted above, the project aims to be cross-platform. Much of the code is said to have been cleaned up and numerous bugs have been fixed.

Still, the (IMO) annoying /*@ comments/annotations remain (e.g. rpmqv.c):

/*@-bounds@*/ /* LCL: segfault */
/*@-mods@*/ /* FIX: shrug */
#if !defined(__GLIBC__) && !defined(__LCLINT__)
int main(int argc, const char ** argv, /*@unused@*/ char ** envp)
#else
int main(int argc, const char ** argv)
#endif
        /*@globals rpmEVR, RPMVERSION,
                rpmGlobalMacroContext, rpmCLIMacroContext,
                h_errno, fileSystem, internalState@*/
        /*@modifies fileSystem, internalState@*/

popt.h, since it happens to look the very same:

/*@only@*/ /*@null@*/
poptContext poptGetContext(
                /*@dependent@*/ /*@keep@*/ const char * name,
                int argc, /*@dependent@*/ /*@keep@*/ const char ** argv,
                /*@dependent@*/ /*@keep@*/ const struct poptOption * options,
                unsigned int flags)
        /*@*/;

It suffices to say that I prefer documenting exported API outside the code. And for internal APIs/functions, document it the linux-kernel way. YMMV.

>Supported compression formats now include bzip, bzip2 and LZMA. Initial support has been added for XAR, the XML Archive file format, while support for the old RPMv3 format has been removed.

LZMA is welcomed. RPMv3 should have been retained, probably with a simple plugin architecture (or struct with a bunch of pointers, something along the lines of inode_operations in linux).

The launch of RPM 5.0

Posted Jan 10, 2008 23:08 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Still, the (IMO) annoying /*@ comments/annotations remain (e.g. rpmqv.c):

These are annotations for Splint (a "tool for statically checking C programs for security vulnerabilities and coding mistakes"). Not a bad idea, if you ask me...

The launch of RPM 5.0

Posted Jan 11, 2008 13:31 UTC (Fri) by n3npq (guest, #40075) [Link]

Plugin's and data structures cannot address interoperable compatibility for RPMv3 file 
format  issues. The previous implementation (RPMv4 was introduced over 5 years ago) actually 
had  inode_operation like vectors, and a plugin-in architecture was anticipated. 5+ years of 
experience  with the implementation has shown that it was the wrong approach.

However, rpm-5.0 still queries and installs RPMv3 packages. What has been removed is support 
for header+payload signatures as used in RPMv3 format. Additional information included in 
RPMv4 headers prevents compatibility because the digitally signed plaintext is different.

Meanwhile, rpm is moving to XAR in the future. XAR is a better archive format, more  easily  
extended, with per-file compression, is structurally the same as existing rpm packages 
with  all metadata stored before  the payload files for streaming, and uses XML to represent 
metadata so that other  tools than rpm can more  easily import/export  package metadata.

One of the immediate and  obvious benefits of using XAR is that package metadata is 
compressed, so a  *.xar archive is actually  smaller than *.rpm for identical content.

Yes, splint comments are very annoying and pugly. The end-result of the annoyance is better 
code  checking. E.g. splint was invaluable refactoring rpm-5.0 code.

Splint annotations are not  documentation, but static assertions that can be checked by an  
automated tool.

The launch of RPM 5.0

Posted Jan 11, 2008 14:02 UTC (Fri) by jengelh (subscriber, #33263) [Link]

>with per-file compression

I have to disagree, at least for files whose size is smaller than the compressor block size. And that is often the case - manpages, documentation files, they are usually below 900 KB (bzip2 -9 size). So "solid compression", as DOS/Win32 archivers call it, is much more preferable, especially since you usually install all files that are inside an .rpm.

>Splint annotations are not documentation, but static assertions that can be checked by an automated tool.

Still, I would have preferred LK-style tags:

#ifndef __SPLINT__
#       ifndef __splint_only
#               define __splint_only
#       endif
#       ifndef __splint_keep
#               define __splint_keep
#       endif
#endif

__splint_only __splint_null poptContext
poptGetContext(__splint_dependent __splint_keep const char *name,
               int argc,
               __splint_dependent __splint_keep const char **argv,
               __splint_dependent __splint_keep const struct poptOption *options,
               unsigned int flags);

While requiring a few extra #defines to map these to nothing (or even have an #include <splint_tags.h> that does this), they are much cleaner and do not get highlighted as comments. Yeah, maybe I could add an exclude rule in the syntax highlighting for "comments" starting with /*@, but still.

Then there are the real comments, introduced by /*!. popt(3) documents the interface much better than the extra few words in popt.h

The launch of RPM 5.0

Posted Jan 11, 2008 14:55 UTC (Fri) by n3npq (guest, #40075) [Link]

The goal is to get compression issues _OUT_ of rpm itself and
into a XAR archive layer. E.g. LZMA is extremely interesting and useful
and (without well defined magic) almost impossible to use reliably
at the moment. Yes all this is changing rapidly (and rpm-5.0
will be upgraded at first opportunity)

Re: LK-style tags is all I can say is "Icky-poo."

The right thing to do is to use scan.coverity.com instead of
splint static annotations. Static code checking has improved
immensely in the last 5 years (since I've been using splint).
The maintenenance alone of splint annotations is a huge waste
of my time (but does lead to better code so I make the effort).

Ironically, scan.coverity.com somehow believes that 9 year old rpm-2.4.9
from NetBSD is what is useful checked, largely because that is the version of rpm
that is packaged by NetBSD.

So if you _REALLY_ want all the splint annotations out of rpm code, then _PLEASE_
help by packaging up some more modern version of rpm than 2.4.9 for NetBSD.

I'll rip the pugly splint annotations in a flash if/when scan.coverity.com is
functional on rpm-5.0 code.

Meanwhile, I use last-known-good, just like everyone else.