Udgivelsen af RPM-pakkehåndtereren 4.20 og starten på udviklingen af RPM 6

Efter et års udvikling blev pakkehåndteringssystemet RPM 4.20.0 frigivet. RPM4-projektet udvikles af Red Hat og bruges i distributioner som RHEL, Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS og Tizen. Projektets kode distribueres under GPLv2 og LGPLv2-licenserne.

I det kommende år forventes offentliggørelsen af en betydelig version af RPM 6, som vil anvende et nyt arkivformat, der i modsætning til det nuværende cpio-format vil muliggøre oprettelse af pakker, der er større end 4 GB (denne grænse er vigtig, da SRC-pakken med Chromium nærmer sig grænsen og har en størrelse på 3,7 GB). I den nye version planlægges det også at tillade brug af C++ til udvikling af RPM. Den nye betydelige version vil blive fejret i anledning af projektets jubilæum — den 27. november 2025 vil det være 30 år siden den første commit i RPM. Versioner af RPM 5.x vil blive udeladt for at undgå overlap med RPM5-projektet, som ikke er direkte relateret til RPM fra Red Hat, da det blev udviklet af et uafhængigt team af udviklere og ikke er blevet opdateret siden 2016.

De mest markante forbedringer i RPM 4.20:

  • Et nyt værktøj, rpm2archive, er blevet inkluderet, hvilket afløser værktøjet rpm2cpio og vil i fremtiden forenkle overgangen til det nye pakkeformat, som ikke anvender cpio. I modsætning til rpm2cpio konverterer det nye værktøj RPM-filen ikke til et cpio-arkiv, men til et tar-arkiv, der er komprimeret med gzip. Det gamle værktøj rpm2cpio er blevet erstattet med et symbolsk link til rpm2archive.
  • Der er foreslået et deklarativt byggesystem, baseret på brugen af den nye direktiv "BuildSystem", gennem hvilket byggesystemet, der anvendes ved pakkeoprettelse, kan defineres. Kildekoden forberedes automatisk, kompileres og installeres under hensyntagen til det angivne byggesystem, uden behov for at definere separate scripts i SPEC-filen til forberedelse, bygning og installation i sektionerne "%prep", "%build" og "%install". I RPM bestemmes de understøttede byggesystemer i form af makro-samlinger.

    Den grundlæggende idé er, at det deklarative konfigurationsformat gør det muligt for distributionsudviklere at oprette separate makroer til standardiserede byggeprocesser, så de ikke behøver at definere gentagne scripts i hver pakke. For eksempel, i stedet for at definere rækkefølgen af kommandoerne configure og make for programmer, der bruger Autotools, er det nu tilstrækkeligt at angive "BuildSystem: autotools" og undgå sektionerne "%prep", "%build" og "%install". I øjeblikket er sådanne makroer forberedt til Autotools og CMake. Hvis der er behov for at implementere ikke-standardiseret adfærd, er pakkevedligeholderne givet mulighed for at tilslutte deres egne makroer for at tilsidesætte forskellige faser af pakkeoprettelsen.

  • Der er tilføjet støtte til vedhæftning af yderligere sektioner med kommandoer til forberedelse, bygning, installation, konfiguration, oprydning og verificering, som supplerer de grundlæggende sektioner %prep, %conf, %build, %install, %check og %clean. For at køre et ekstra script før udførelsen af koden fra den grundlæggende sektion er der foreslået muligheden "-p", og efter den grundlæggende sektion — muligheden "-a". Sådanne substitutioner kan vise sig at være nyttige til finjustering af adfærden, når den ovenfor beskrevne deklarative byggetilstand anvendes.
  • Det er tilladt at inkludere direktiver og sektioner i dynamisk genererede SPEC-filer, der ikke påvirker byggeprocessen.
  • Makroen %builddir er blevet tilføjet, og en administreret gennem RPM-mulighed er blevet implementeret til at binde egne bygge kataloger til separate pakker.
  • En ny protokol "multi-file" er blevet foreslået, som væsentligt accelererer genereringen af afhængigheder.
  • Der er tilføjet en mulighed "—json" til rpm-kommandoen for at udskrive resultatet af forespørgsler i JSON-format.
  • Der er tilføjet en rpm-plugin-unshare, der sikrer isolation af scripts, der udføres i bygge sektionerne, ved at bruge navnerum i Linux. For eksempel gør plugin’et det muligt at forbyde adgang til netværket og begrænse adgangen til filsystemet samt bruge separate private kataloger /tmp og /home for at beskytte i tilfælde af usikkert arbejde med midlertidige filer under pakkeoprettelsen.
  • Der er foreslået et offentligt API til udvikling af plugins, som skal bevare kompatibiliteten mellem versioner. Tidligere var API'et til plugins kun beregnet til intern brug og kunne ændre sig fra version til version.
  • Der er tilføjet mulighederne "—list" og "—delete" til rpmkeys-kommandoen.
  • Team rpmsign har tilføjet støtte til at oprette digitale signaturer for pakker ved hjælp af ECDSA-nøgler.
  • Støtten til gentagne builds er forbedret. Makroen «%build_mtime_policy» er tilføjet, hvilket giver mulighed for at styre indholdet af tidsstempler, der tilføjes ved bygning (gennem værdien clamp_to_source_date_epoch kan en fast tidsstempel bruges, mens clamp_to_buildtime angiver den faktiske byggetid).
  • I sysusers.d-filer er det nu tilladt at tilføje linjer til at definere medlemmer af grupper.
  • Korrekt og distributionsuafhængig støtte til debuginfo-filer er sikret.
  • Syntaksen for makroer %patchN (uden mellemrum før N) er blevet erklæret forældet, og brug af denne vil nu medføre fejl (brug venligst syntaksen «%patch N» eller «%patch -P N», hvor N er patch-nummeret).
  • Den forældede OpenPGP-parser er blevet fjernet.
  • Afhængighedsgeneratorer for Perl og Python ABI er flyttet til separate repositories.

Kilde: opennet.ru

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster