News from the RPM pits

Father, it’s been a while since I last blogged…

Doesn’t mean nothing has been going on, not at all. Yesterday RPM maintenance update was released with a fairly long list of bugfixes. The changelog has the details but various longstanding issues such as spaces in filenames, incorrect return codes from queries, “rpmbuild -bb –target <otherarch>” putting libraries to wrong directories on multilib systems etc have been fixed finally. This is the version that will be in Fedora 9, and it’s already in Rawhide.

Oh, I fully agree – maintenance updates to RPM 4.4.x aren’t particularly exciting. Maintenance releases of stable software are not supposed to be exciting! RPM isn’t the kind of software distros update lightly, it’s the very corner stone of RPM-based distributions: if it breaks, everything stops. So getting bugfixes to stable branch delivered in a predictable, no-surprises manner is of utmost importance. Exciting it is not.

Doesn’t mean there aren’t any exciting news though. RPM has just recently gotten more developer manpower behind it: Florian Festi and Jindrich Novy (both from Red Hat) are now working on RPM with me more or less full-time. This should give a nice boost to RPM development, cheers to Florian and Jindrich and my boss Denise who made this happen!

So, where’s the next major release lurking? Starting to be visible in the horizon, I would say. We’re still largely just clearing up ancient messes in the codebase – tedious, hard and largely thankless job of auditing and fixing the codebase for things like type- and const-correctness (rpm is/was full of code deliberately freeing data declared const for example), eliminating potential buffer overflows, splitting 1000+ line functions into smaller verifiable pieces, rewriting obscure code to be more readable, removing nasty surprises from the API and so on. Sexy new features – assuming one thinks there are such things in the world of RPM in the first place – are few and far between at the moment, we’ve been mostly removing “features” that don’t belong to RPM or are simply unsupportable. We want to make the ground solid before starting building anything new on it, even if it takes more time than one would like.

The time for actual new development work is closing in though, especially now with more folks actively working on RPM. Many things are in design phase, some already started like brand new Python bindings:

Rpm-python bindings are getting a thorough rewrite + redesign. The new bindings are being developed outside rpm proper and will be differently namespaced and parallel-installable to the current ones to allow for easy transition, the old in-rpm bindings will be maintained as long as necessary. While this does mean some extra (duplicated) work, it’s IMO the only way to get rid of various misdesigns, bad API’s and limitations of the current bindings without breaking the entire package build + management stack at once. The new bindings will be a mixture of Python and C with only low-level interface to librpm written in C, so if you want to hack on RPM stuff but only know Python, this is no problem anymore.

Other things that we’re looking at / going to look at include (but by no means limited to) multilib/arch dependencies, generic dependency filtering and custom dependency extractor mechanisms, redesigning the ancient transaction callback interface for extensibility, transaction performance and memory consumption issues, better API for header data handling … etc. The list is rather endless, and not all of it is going to happen now, or even this year. What I want to say here is that we’re not just sitting still on RPM 4.4.2.x, we’re working hard on delivering a solid new release, your patience is appreciated. 😉

Comments are closed.