The launch of RPM 5.0

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:

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

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.

/*@-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@*/

/*@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)
        /*@*/;

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.

#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);

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.