A RPM 4.20 paketkezelő kiadásának bejelentése és a RPM 6 fejlesztésének megkezdése

A RPM 4.20.0 paketkezelő kiadása egy év tervezés után történt. Az RPM4 projektet a Red Hat fejleszti, és olyan disztribúciókban használják, mint az RHEL, Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS és Tizen. A projekt kódja GPLv2 és LGPLv2 licenc alatt terjesztett.

A következő évben várható a jelentős RPM 6 ág közzététele, amely új archív formátumot alkalmaz, lehetővé téve a 4 GB-nál nagyobb méretű csomagok létrehozását a jelenleg használt cpio formátummal ellentétben (ez a korlátozás meghaladása fontos, mivel a Chromium SRC-csomagja közel áll a határértékhez, és mérete 3.7 GB). Az új ágba a C++ nyelv használatát is tervezik a RPM fejlesztéséhez. Az új jelentős ágat a projekt jubileumára időzítik — 2025. november 27-én lesz 30 éve, hogy az első commitot elhelyezték az RPM-ben. Az RPM 5.x verziók kihagyásra kerülnek, hogy elkerüljék a közbenső átfedéseket az RPM5 projekttel, amely nincs közvetlen kapcsolatban a Red Hat RPM-mel, független fejlesztői csapat által fejlődött és 2016 óta nem frissítik.

A legfontosabb fejlesztések az RPM 4.20-ban:

  • Megjelent egy új rpm2archive segédprogram, amely felváltotta az rpm2cpio segédprogramot, és a jövőben megkönnyíti az új archív formátumra való áttérést, amely nem használ cpio-t. Az rpm2cpio-val ellentétben az új segédprogram nem cpio archívumot, hanem gzip tömörítéssel ellátott tar archívumot hoz létre az RPM fájlból. A régi rpm2cpio segédprogram szimbolikus hivatkozásra lett cserélve az rpm2archive-ra.
  • Javasolt egy deklaratív build rendszer, amely új „BuildSystem” direktíván alapul, amelyen keresztül meghatározható a csomag alakításához használt build rendszer. A forráskód automatikusan előkészül, lefordul és települ a megadott build rendszer figyelembevételével, anélkül, hogy a SPEC fájlban külön kellene meghatározni az előkészítési, buildelési és telepítési szkripteket a „%prep”, „%build” és „%install” blokkban. Az RPM-ben a támogatott build rendszerek makrógyűjtemények formájában vannak megadva.

    A fő ötlet az, hogy a deklaratív konfigurációs formátum lehetővé teszi a disztribúciók fejlesztői számára, hogy különböző makrókat hozzanak létre a tipikus összeállítási folyamatokhoz, így nem szükséges minden csomagban ismétlődő forgatókönyveket definiálni. Például az Autotools-t használó programoknál a configure és make parancsok sorozatainak meghatározása helyett most elég csupán annyit megadni, hogy „BuildSystem: autotools”, és elkerülhető a „%prep”, „%build” és „%install” szakaszok használata. Jelenleg az Autotools és a CMake számára ilyen makrók állnak rendelkezésre. Ha szükséges a nem szabványos viselkedés megvalósítása, a csomagokat kezelő felhasználóknak lehetőségük van saját makróik csatlakoztatására, amely lehetővé teszi a csomagformálás különböző szakaszainak felülírását.

  • Hozzáadva a kiegészítő szakaszok csatolásának támogatása a felkészülési, építési, telepítési, konfigurálási, tisztítási és ellenőrzési parancsokhoz, amelyek kiegészítik az alapvető %prep, %conf, %build, %install, %check és %clean szakaszokat. Kiegészítő szkript futtatására, a alap szakaszok kódja előtt, a „-p” opció, míg utánuk az „-a” opció ajánlott. Ilyen helyettesítések hasznosak lehetnek a fenti deklaratív építési mód használatakor a viselkedés pontos korrekciójára.
  • A SPEC fájlok dinamikusan létrehozott részeibe olyan direktívák és szakaszok illeszthetők, amelyek nem befolyásolják az összeállítási folyamatot.
  • Hozzáadva a %builddir makró és megvalósítva az RPM-en keresztül irányított lehetőség, amely lehetővé teszi a saját építési könyvtárak hozzárendelését külön csomagokhoz.
  • Javasolt egy új „multi-file” protokoll, amely jelentősen felgyorsítja a függőségek generálását.
  • Az rpm parancshoz hozzáadva a „—json” opció, amely lehetővé teszi a lekérdezések eredményeinek JSON formátumban történő kiíratását.
  • Hozzáadva az rpm-plugin-unshare plugint, amely izolálja a csomagok összeállító szakaszaiban végrehajtott szkripteket, a Linux névtér felhasználásával. Például ez a plugin megakadályozza a hálózati hozzáférést és korlátozza a fájlrendszerhez való hozzáférést, valamint külön privát könyvtárakat használ a /tmp és /home védelme érdekében, ha a csomagok telepítése közben nem biztonságos átmeneti fájlokkal dolgoznak.
  • Javasolt egy nyilvános API a pluginek fejlesztéséhez, amely megőrzi a verziók közötti kompatibilitást. Korábban a pluginok API-ját kizárólag belső használatra tervezték, és verzióról verzióra változhatott.
  • Az rpmkeys parancshoz hozzáadva a „—list” és „—delete” opciók.
  • A rpmsign csapatába bekerült az ECDSA kulcsokkal történő digitális aláírások készítésének támogatása.
  • Javult a repetitív build-ek támogatása. Bevezetésre került a „%build_mtime_policy” makró, amely lehetővé teszi a build során hozzáadott címkék időtartalmának kezelését (a clamp_to_source_date_epoch értékkel fix címkét, míg a clamp_to_buildtime segítségével a tényleges build időpontját adhatja meg).
  • A sysusers.d fájlokhoz mostantól lehetőség van a csoporttagok meghatározására szolgáló sorokat hozzáadni.
  • Biztosított a helyes és disztribúcióktól független debuginfo fájlok támogatása.
  • Elavulttá nyilvánították a %patchN (N előtt szóköz nélkül) makrók szintaxisát, használatuk mostantól hibához vezet; a helyes szintaxis a „%patch N” vagy a „%patch -P N”, ahol N a javító száma.
  • Eltávolították az elavult OpenPGP parsert.
  • A Perl és Python ABI függőségi generátorokat külön tárolókba helyezték.

Forrás: opennet.ru

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster