{"id":120153,"date":"2024-10-12T13:09:06","date_gmt":"2024-10-12T11:09:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-paketnogo-menedzhera-rpm-4-20-i-nachalo-razrabotki-rpm-6"},"modified":"2024-10-12T13:09:06","modified_gmt":"2024-10-12T11:09:06","slug":"vypusk-paketnogo-menedzhera-rpm-4-20-i-nachalo-razrabotki-rpm-6","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/vypusk-paketnogo-menedzhera-rpm-4-20-i-nachalo-razrabotki-rpm-6","title":{"rendered":"Release of package manager RPM 4.20 and start of development of RPM 6","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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. <\/p>\n
Next year, a significant branch of RPM 6 is expected to be released, which will utilize a new archive format that allows for creating packages larger than 4 GB, overcoming the current limitation of the cpio format. This is crucial since the SRC package for Chromium is nearing that limit at 3.7 GB. The new branch will also permit the use of C++ for RPM development. This major release will coincide with the project's anniversary\u2014November 27, 2025 marks 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 the RPM by Red Hat and has not been updated since 2016. <\/p>\n
The most notable improvements in RPM 4.20 include: <\/p>\n
\n
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.\n
A declarative build system has been proposed, based on a new directive 'BuildSystem', through which the build system used to create a package can be defined. The source code is automatically prepared, compiled, and installed considering the specified build system, without needing separate definitions in the SPEC file for preparation, build, and installation scripts in the '%prep', '%build', and '%install' sections. In RPM, supported build systems are defined in the form of macro collections.\n
The main idea is that the declarative configuration format will allow distribution developers to create separate macros for typical build processes, eliminating the need to define repetitive scripts in every package. For instance, instead of specifying the sequence of commands for configure and make for programs using Autotools, it is now sufficient to specify 'BuildSystem: autotools', thereby bypassing the '%prep', '%build', and '%install' sections. Currently, such macros have been prepared for Autotools and CMake. If custom behavior needs to be implemented, package maintainers are provided with the option to connect their own macros to override various stages of package formation. <\/p>\n
Support for attaching additional sections with preparation, building, installation, configuration, cleaning, and checking commands has been added, complementing the basic sections %prep, %conf, %build, %install, %check, and %clean. An option '-p' has been proposed to run an additional script before executing the code from the basic section, and an option '-a' after the basic section. Such substitutions may be useful for fine-tuning behavior when using the aforementioned declarative build mode.\n
Directives and sections that do not affect the build process are now allowed in dynamically generated parts of SPEC files.\n
A %builddir macro has been added, along with a managed capability through RPM to bind custom build directories to individual packages.\n
A new 'multi-file' protocol has been introduced, significantly speeding up dependency generation.\n
The rpm command has been enhanced with the '--json' option for outputting query results in JSON format.\n
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.\n
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.\n
The rpmkeys command has been updated with the '--list' and '--delete' options.\n
The rpmsign command now supports creating digital signatures for packages using ECDSA keys.\n
Support for repeatable builds has been improved. The macro '%build_mtime_policy' has been added, allowing management of the content of timestamps added during the build (the value clamp_to_source_date_epoch can be used to fix the timestamp, while clamp_to_buildtime specifies the actual build time).\n
In sysusers.d files, it is now allowed to add lines to define group members.\n
Correct and distribution-independent support for debuginfo files has been ensured.\n
The syntax of the %patchN macros (without a space before N) has been deprecated, and its use will now result in an error (the syntax '%patch N' or '%patch -P N' should be used, where N is the patch number).\n
The deprecated OpenPGP parser has been removed.\n
Dependency generators for Perl and Python ABI have been moved to separate repositories. <\/ul>\n