Next Major RPM Version

[ffesti]

Those who have been following RPM development already know that we have been thinking about the next major release of RPM for quite a while. We are finally ready to give a rough outline of where this is all going.

Next Major Version

One point of discussion was which version number to pick. With 5 being out of the question, 6, 4.100 and 5b were contenders until someone suggested "tau". Tau (also know as two pi) - with a numeric value of 6.2831853... - is a round number just outside of the range of controversy. We will from now on skip all "bad" uneven version numbers. So after tau we will got right to the alternative true value of two times pi: 8

Rusty Code

The RPM code base is getting old and beside all efforts to modernize it just doesn't match the requirements of the 21st century. As the new crypto and signature handling back end is already been written in Rust we will rewrite the rest of RPM in Rust, too. Software based on RPM is expected to do the same to ensure the same level of security throughout the whole software handling stack. While we'd love to see that programs executing rpm - like shells - are also be re-written in Rust we currently have not found a way to technically enforce this.

Project Name

Beside the huge technical benefits of this re-write it also gives RPM back a proper acronym. Instead of RPM just meaning RPM Package Manager it will from now on mean "Rusty Package Manager".

Systemd

Another goal of the re-write is to integrate RPM further into systemd. RPM being a system service will make command
line and GUI applications much easier. In the future Package can be installed or removed via dbus message - both simple NEVRA and complex queries will be supported. Package not available in a repository can be send whole as base64 encoded blob or just dumped into /usr/lib/packages.d/rpm/

Hands free Packaging

On the build side we want to finally get our push to reduce Spec files to a completion. The new, mostly internal, XML based spec format will be created automatically during package build. An AI based packager (sorry, no other details - yet) will turn manifest files, INSTALL.TXT, setup.py and others into Spec file fragments. It will support all common programming languages and also common build systems, like automake, cmake, etc. The newly added Dynamic Spec feature (https://rpm-software-management.github.io/rpm/manual/dynamic_specs.html) has allows testing the viability of this approach already. The AI has been trained with the spec files of well known Linux distributions. But more manual tweaking is still necessary.

For legacy packages there will be a rpmspec2xml tool available that is also automatically used when passing legacy spec files to rpmbuild. For new style packages packagers basically just have to put the sources and patches into a directory (assuming the changelog file is automatically generated from a git commit log) and call rpmbuild -ba .

ETA

rpm-tau.0-alpha is expected to be release in exactly one year at the 1st of April 2024.

[ffesti]

Happy April's fool day everyone!