Release of package manager RPM 4.20 and start of development of RPM 6

After a year of development, the release of package manager RPM 4.20.0 has occurred. The RPM4 project is developed by Red Hat and is used in distributions such as RHEL, Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS, and Tizen. The project's code is distributed under the GPLv2 and LGPLv2 licenses.

Next year, a significant branch of RPM 6 is expected to be published, featuring a new archive format that allows for the creation of packages larger than 4 GB, unlike the currently used cpio format (overcoming this limitation is important as the SRC package for Chromium is close to the threshold and is 3.7 GB in size). The new branch also intends to allow the use of C++ for RPM development. This major branch will coincide with the anniversary of the project — on November 27, 2025, it will be 30 years since the first commit to RPM. Versions RPM 5.x will be skipped to avoid overlaps with the RPM5 project, which is not directly related to Red Hat's RPM, developed by an independent team of developers, and has not been updated since 2016.

The most notable improvements in RPM 4.20 include:

  • A new utility rpm2archive has been added, which replaces the rpm2cpio utility and will further simplify the transition to the new package format that does not use cpio. Unlike rpm2cpio, the new utility converts an RPM file into a tar archive compressed with gzip. The old rpm2cpio utility has been replaced by a symbolic link to rpm2archive.
  • A declarative build system has been proposed, based on the use of the new directive "BuildSystem," through which the build system used for package creation can be defined. The source code is automatically prepared, compiled, and installed according to the specified build system, without the need for separate definitions in the SPEC file for preparation, building, and installation scripts in the "%prep," "%build," and "%install" blocks. Supported build systems in RPM are defined in the form of macro collections.

    The main idea is that a declarative configuration format will allow distribution developers to create separate macros for typical build processes, thereby avoiding the need to define repetitive scripts in each package. For instance, instead of defining the sequences for running the configure and make commands for programs using Autotools, it is now sufficient to specify 'BuildSystem: autotools' and skip the '%prep', '%build', and '%install' sections. Currently, such macros have been prepared for Autotools and CMake. If non-standard behavior is required, package maintainers have the option to connect their own macros to override different stages of package creation.

  • Support has been added for attaching additional sections with preparation, build, installation, configuration, cleanup, and check commands, complementing the basic sections %prep, %conf, %build, %install, %check, and %clean. To run an additional script before executing code from the base section, the '-p' option has been proposed, and after the base section, the '-a' option. Such substitutions can be useful for precise adjustments in behavior when using the aforementioned declarative build mode.
  • Directives and sections that do not affect the build process are now allowed in dynamically generated parts of SPEC files.
  • A %builddir macro has been added, along with a managed capability through RPM to bind custom build directories to individual packages.
  • A new 'multi-file' protocol has been proposed, significantly speeding up dependency generation.
  • The rpm command has been enhanced with the '--json' option for outputting query results in JSON format.
  • The rpm-plugin-unshare plugin has been added, providing isolation for scripts executed in build sections by using namespaces in Linux. For example, the plugin allows for network access restrictions and filesystem access limitations, as well as the use of separate private directories /tmp and /home to protect against unsafe handling of temporary files during package builds.
  • A public API for plugin development has been proposed, which will maintain compatibility across releases. Previously, the plugin API was intended solely for internal use and could change from release to release.
  • The rpmkeys command has been enhanced with the '--list' and '--delete' options.
  • The rpmsign command now supports creating digital signatures for packages using ECDSA keys.
  • Improved support for repeatable builds. Added the macro "%build_mtime_policy", which allows controlling the content of timestamps added during the build (you can use a fixed timestamp with the value clamp_to_source_date_epoch and specify the actual build time with clamp_to_buildtime).
  • In sysusers.d files, it is now allowed to add lines to define group members.
  • Correct and distribution-independent support for debuginfo files has been ensured.
  • The syntax of the %patchN macros (without a space before N) is deprecated, and its usage will now lead to an error (the syntax "%patch N" or "%patch -P N" should be used, where N is the patch number).
  • The deprecated OpenPGP parser has been removed.
  • Dependency generators for Perl and Python ABI have been moved to separate repositories.

Source: opennet.ru

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster