Po roku prac rozwojowych zrealizowano wydanie menedżera pakietów RPM 4.20.0. Projekt RPM4 jest rozwijany przez firmę Red Hat i używany w takich dystrybucjach jak RHEL, Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS i Tizen. Kod projektu jest udostępniany na licencjach GPLv2 i LGPLv2.
W przyszłym roku planowane jest opublikowanie znaczącej gałęzi RPM 6, w której zastosowany zostanie nowy format archiwum, umożliwiający, w przeciwieństwie do obecnie stosowanego formatu cpio, tworzenie pakietów o rozmiarze większym niż 4 GB (przełamanie tego ograniczenia jest istotne, ponieważ pakiet SRC z Chromium zbliża się do tego limitu i ma rozmiar 3.7 GB). W nowej gałęzi zamierzają również umożliwić korzystanie z języka C++ do rozwoju RPM. Nowa znacząca gałąź będzie również związana z jubileuszem projektu — 27 listopada 2025 roku minie 30 lat od pierwszego commita w RPM. Wersje RPM 5.x zostaną pominięte, aby wykluczyć nakładanie się z projektem RPM5, który nie jest bezpośrednio związany z RPM od Red Hat, rozwijał się pod kierunkiem niezależnego zespołu programistów i nie jest aktualizowany od 2016 roku.
Najbardziej zauważalne ulepszenia w RPM 4.20:
- Do pakietu dołączono nowe narzędzie rpm2archive, które zastąpiło narzędzie rpm2cpio i w przyszłości ułatwi przejście na nowy format pakietów, nie używający cpio. W przeciwieństwie do rpm2cpio, nowe narzędzie przekształca plik RPM nie w archiwum cpio, a w archiwum w formacie tar, skompresowanym za pomocą gzip. Stare narzędzie rpm2cpio zostało zastąpione dowiązaniem symbolicznym do rpm2archive.
- Proponowany jest deklaratywny system budowy, oparty na nowej dyrektywie „BuildSystem”, przez którą można określić system budowy stosowany podczas tworzenia pakietu. Kod źródłowy jest automatycznie przygotowywany, kompilowany i instalowany z uwzględnieniem określonego systemu budowy, bez konieczności oddzielnego definiowania w pliku SPEC skryptów przygotowawczych, budowlanych i instalacyjnych w blokach „%prep”, „%build” i „%install”. W RPM wspierane systemy budowy są definiowane w formie kolekcji makro.
Główna idea polega na tym, że deklaratywny format konfiguracji pozwoli deweloperom dystrybucji tworzyć oddzielne makra dla typowych procesów budowy, aby nie definiować powtarzających się skryptów w każdym pakiecie. Na przykład, zamiast definiować sekwencje uruchamiania poleceń configure i make dla programów korzystających z Autotools, teraz wystarczy wskazać „BuildSystem: autotools” i ominąć sekcje „%prep”, „%build” oraz „%install”. Aktualnie takie makra są przygotowane dla Autotools i CMake. W razie potrzeby wdrożenia niestandardowego zachowania, osobom zajmującym się pakietami została udostępniona możliwość dołączenia własnych makr do nadpisania różnych etapów formowania pakietu.
- Dodano wsparcie dla dołączania dodatkowych sekcji z poleceniami przygotowania, budowy, instalacji, konfiguracji, czyszczenia i testowania, uzupełniających podstawowe sekcje %prep, %conf, %build, %install, %check i %clean. Aby uruchomić dodatkowy skrypt przed wykonaniem kodu z podstawowej sekcji, zaproponowano opcję „-p”, a po podstawowej sekcji — opcję „-a”. Takie podstawienia mogą okazać się przydatne do punktowego dostosowania zachowania w użyciu powyżej opisanego deklaratywnego trybu budowy.
- Do dynamicznie tworzonych części plików SPEC zezwala się na włączanie dyrektyw i sekcji, które nie wpływają na proces budowy.
- Dodano makro %builddir i zrealizowano zarządzaną przez RPM możliwość przypisywania własnych katalogów budowlanych do oddzielnych pakietów.
- Zaproponowano nowy protokół „multi-file”, znacznie przyspieszający generację zależności.
- Do polecenia rpm dodano opcję „—json” do wyjścia wyników zapytań w formacie JSON.
- Dodano wtyczkę rpm-plugin-unshare, zapewniającą izolację skryptów wykonywanych w sekcjach budowy przy użyciu przestrzeni nazw w systemie Linux. Na przykład, wtyczka umożliwia zablokowanie dostępu do sieci oraz ograniczenie dostępu do systemu plików, a także wykorzystanie oddzielnych prywatnych katalogów /tmp i /home w celu ochrony w przypadku niebezpiecznej pracy z plikami tymczasowymi podczas budowy pakietów.
- Zaproponowano publiczny interfejs API do opracowywania wtyczek, który zachowa kompatybilność między wersjami. Wcześniej API dla wtyczek było przewidziane tylko do wewnętrznego użytku i mogło się zmieniać z wersji na wersję.
- Do polecenia rpmkeys dodano opcje „—list” i „—delete”.
- Do zespołu rpmsign dodano wsparcie dla tworzenia podpisów cyfrowych dla pakietów, z użyciem kluczy ECDSA.
- Ulepszono wsparcie dla powtarzalnych kompilacji. Dodano makro „%build_mtime_policy”, umożliwiające zarządzanie zawartością dodawanych podczas kompilacji znaczników czasowych (poprzez wartość clamp_to_source_date_epoch można użyć stałego znacznika, a przez clamp_to_buildtime określić rzeczywisty czas kompilacji).
- W plikach sysusers.d zezwolono na dodawanie wierszy do definiowania członków grupy.
- Zapewniono poprawne i niezależne od dystrybucji wsparcie dla plików debuginfo.
- Została ogłoszona deprecjacją składnia makr %patchN (bez spacji przed N), której użycie teraz będzie prowadzić do błędu (należy użyć składni „%patch N” lub „%patch -P N”, gdzie N to numer łaty).
- Usunięto przestarzały parser OpenPGP.
- Generatory zależności dla Perl i Python ABI zostały przeniesione do osobnych repozytoriów.
Źródło: opennet.ru
